TRAVIS COUNTY PURCHASING OFFICE 
Cyd V. Grimes, C.P.M., CPPO, Purchasing Agent 


700 Lavaca, "Suite 800 " Austin, Texas 78701 " (512) 854-9700 " Fax (512) 854-9185 


October 6, 2016 


Dear Proposers: 


You are invited to submit proposals in accordance with the attached specifications packet, Request For 
Proposal (RFP) # P1609-008-LC, for STAR-Vote™: A New Voting System for Travis County, Texas. 
All proposals must be submitted with an Original and five (5) copies plus two (2) electronic copies (in 
searchable PDF format on a flash drive) to the Travis County Purchasing Agent, 700 Lavaca, Suite 800, 
Austin, Texas 78701, no later than 2:00 p.m., December 16, 2016. 


An optional pre-proposal conference is scheduled for 12:30 p.m., October 19, 2016 at the Travis County 
Purchasing Office, Large Conference Room located at 700 Lavaca, Suite 800, Austin, Texas 78701. 


FOR ANY INFORMATION RELATED TO THIS RFP, THE PROPOSER MAY CONTACT ONLY CYD 
GRIMES, PURCHASING AGENT; BONNIE FLOYD, ASSISTANT PURCHASING AGENT; OR LORI 
CLYDE, PURCHASING AGENT ASSISTANT IV. CONTACT WITH ANY OTHER PERSON 
ASSOCIATED WITH THIS RFP MAY RESULT IN DISQUALIFICATION OF THE PROPOSAL. 


All proposals shall be submitted to the Travis County Purchasing Agent in a sealed envelope marked: 


REQUEST FOR PROPOSAL 
STAR-Vote™: A New Voting System 
RFP # P1609-008-LC 
DO NOT OPEN IN MAILROOM 


Your consideration of this request is appreciated. 


Sincerely, 
TRAVIS COUNTY PURCHASING OFFICE 


Cyd V. Grimes, C.P.M., CPPO 
Purchasing Agent 


CVG:LC 
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TRAVIS COUNTY 
REQUEST FOR PROPOSALS (RFP) 
STAR-Vote™: A New Voting System 

RFP # P1609-008-LC 


PART I - GENERAL REQUIREMENTS 
PART I, SECTION A - GENERAL INFORMATION 
PURPOSE: 


This Request for Proposal (RFP) solicits responses from vendors and companies with expertise in 
technology, government, elections, cryptography, statistics, software development, project 
management, and human factors engineering to contract with Travis County for the design, 
development, implementation, maintenance, and continuing evolution of a new voting system we call 
STAR-Vote'M, 


Travis County is interested in companies to be a part of a modern and imaginative election solution 
that incorporates quality software design and development to provide improved security, transparency, 
accuracy, reliability, usability, accessibility, and affordability in the election process. 


STAR stands for Secure, Transparent, Auditable, and Reliable. The STAR-Vote™ system sets new 
standards using the accuracy of electronic voting, the security of cryptography, the transparency of 
paper vote records, the auditability of each step of the election process, and the ability to reliably 
confirm the correct outcomes of each election. 


Travis County is eager for STAR-Vote™ to redefine the polling place experience so that it represents 
today and anticipates the future. The County is building a system that is intuitive for all voters to 
operate and reflects the kind of technology voters are accustomed to seeing in their daily lives; 
enhances options for voters with disabilities; and places reasonable operational demands on election 
workers and administrators. 


Travis County has specified a system that can evolve when improved operating systems, software, and 
hardware enter the marketplace. The County believes the system is flexible and economically 
adaptive to changes in laws and voter demands, has improved modularity and is affordable for all 
counties to purchase, maintain, and upgrade. 


The STAR-Vote™ system requirements were developed from the ground up with the purpose, among 
other objectives, of specifying an entire voting system developed under the open source code software 
model. Building and implementing the complete STAR-Vote™ system requires a wide range of skills 
that are unlikely to be resident within a single company. Furthermore, the practical reality of budget, 
time and functionality required the County to evaluate the best approach that will yield the highest 
likelihood of success. We determined that a phased approach toward complete development and 
implementation, where first phase is defined by this RFP and builds the in-person voting module of the 
STAR-Vote™ system, is the optimum strategy. This RFP is requesting responses for development 
and implementation of the first phase of STAR-Vote™. 


The architecture defined in this RFP has been organized to focus on the implementation of the in- 
person voting polling place system to support Election Day and Early Voting elections. The polling 
place system, or In-Person Voting/Tabulation module, embodies the STAR-Vote™ design for open 


RFP# P1609-008-LC PAGE 6 OF 208 PAGES 

source code, running on COTS hardware and provides a robust security architecture that supports 
Risk-Limiting Audits (RLAs). An objective of this RFP is to contract for the development of the In- 
Person Voting/Tabulation module and the corresponding Support Modules as defined by the STAR- 
Vote™ specifications and requirements. The other open source code components will be developed in 
a follow-on phase. The STAR-Vote™ In-Person Voting/Tabulation module will be supported by 
existing, commercially available, EAC-Certified products, which the County is also seeking to procure 
under this RFP. 


Travis County desires to contract with a company that has existing ballot definition/election 
management, by-mail and tabulation products that are EAC-Certified or that will be EAC-Certified by 
the time of contract award. This architectural approach minimizes the election expertize necessary to 
develop the In-Person Voting/Tabulation module and takes advantage of mature election products. 
The intent is to implement the certified products “as-is” to maintain the certified status. If any 
requirement contained in this RFP conflicts or does not align with existing, certified functionality, the 
County urges the Proposer to simply note the exception in its response for evaluation by the County. 
This RFP intentionally does not provide exhaustive requirements for these products, but is relying on 
the VVSG and the market to validate the functionality. The interface between the In-Person 
Voting/Tabulation module and the certified EAC products is straightforward and utilizes a practice 
that most election products already support: export of an election definition file, and import and 
aggregation of election results. Greater details of this interface will be defined during contract 
negotiations with the contract award finalists. 


The requirements detailed in this RFP follow directly from the Request For Information (RFI) issued 
by Travis County in 2015, and the corresponding responses. The body of system requirements has 
been reorganized to align with the architecture diagram given in Part II, Section 3.1. This RFP allows 
for multiple awards to different vendors and companies to create different elements of the final 
product, and it is possible that awards may be given to two or more different enterprises. Multiple 
awards requires Travis County to provide a system integration function to manage and coordinate the 
interactions between awardees for the length of the contract. The County is prepared to provide this 
level of support to the awardee’s/awardees’ project managers. Further, given the fact that the 
cryptographic solution for STAR-Vote™ is already designed, Travis County will provide design 
support expertise for the software development effort for this functionality. The RFP has been set up 
to solicit separate responses for the different components of the system architecture that will result is 
separate awards and contracts. The components that are open for responses are have been defined as 
separate Elements of the system, and are: 


e Element A; EAC-Certified Modules: Includes election definition, paper ballot formatting, By- 
Mail voting and scanning, tabulation, data import/export, aggregation of results and election 
reporting. 


e Element B; In-Person Voting/Tabulation and Support Modules: This requires the development 
of the software for precinct voting for Early Voting and Election Day that runs on COTS 
hardware and embodies the STAR-Vote™ cryptographic solution. Using the election 
definition data generated by the EAC-Certified Modules, ballots are formatted, voted and 
tabulated. Also includes data import/export, report and the production of artifacts necessary to 
audit and verify the precinct results using the Trustee Utilities and Support Modules, and as 
otherwise outlined in this RFP. 


e Element C; Ballot Box/Scanner: An opportunity exists for a response that includes the use of 
an existing, EAC-Certified precinct-based digital ballot scanner, with a ballot box, that has new 
software developed to support the STAR-Vote™ function of scanning the Paper Vote Record 
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2.0 


3.0 


(PVR) generated by the STAR-Vote™ Voting Station or, ground-up development of new 
hardware and software that is supported by an interim functional solution. 


e Element D; Red Team Assurance: The Red Team Assurance is performed by a group of 
software and security experts who provide independent review of the functional and security 
elements of the system and test the effectiveness of the security. A proposer that responds to 
the In-Person Voting/Tabulation and Support Modules may not bid on the Red Team function. 


e Element E; Human Factors Evaluation: A limited project budget has been created for 
solicitation of a human factors evaluation proposal that focuses on development support and 
assessment of the In-Person Voting function. 


To maintain the overall perspective when drafting a response, Travis County urges Proposers to 
review the complete STAR-Vote™ implementation as given in a paper titled “STAR-Vote™ Voting 
System paper”, found at: 


https://www.usenix.org/conference/evtwote13/workshop-program/presentation/bell 


This Request for Proposal constitutes a solicitation for bids or proposals but does not guarantee that 
any Proposer will be awarded a contract. Travis County has developed the requirements for this 
Request for Proposal (RFP) using information from responses to the RFI and Travis County invites all 
RFI respondents to participate in the RFP process; however, RFI respondents are not provided any 
advantage in the selection process by virtue of having submitted a response to the RFI. Submission of 
an RFP response is entirely voluntary and any and all costs of participation in this process will be the 
complete responsibility of the Proposer. The publication of this RFP does not guarantee that any 
award(s) will be made. 


Travis County cautions Proposers that responses to this RFP will become public information and that 
Proposers should clearly indicate as proprietary and/or confidential any information provided that is of 
a proprietary or confidential nature. 


INCURRED EXPENSES: 


There is no express or implied obligation for Travis County to reimburse Proposers for any expense 
incurred in preparing proposals in response to this request, and Travis County will not reimburse 
anyone for these expenses. Travis County will consider proposals from all responsible Proposers. 


SUBMISSION OF PROPOSAL: 


3.1 To be considered, an ORIGINAL SEALED PROPOSAL PLUS FIVE (5) COPIES and two 
(2) electronic versions must be received by December 16, 2016 at 2:00 p.m., in the office of 
the Purchasing Agent. All proposals must to be addressed to: 


Cyd V. Grimes, C.P.M., CPPO 
Travis County Purchasing Agent 
700 Lavaca, Suite 800 
Austin, Texas 78701 


3.2 The envelope in which the proposal is enclosed must be marked: 


SEALED PROPOSAL 
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3.3 


STAR-Vote™: A New Voting System 
RFP # P1609-008-LC 


DO NOT OPEN IN MAILROOM 


Proposals submitted by electronic transmission will not be considered; however, proposals may 
be modified by electronic transmission if the notice is received prior to the time and date set for 
the proposal opening and specific proposal prices are not exposed by the modification. 


PRE-PROPOSAL CONFERENCE: 


An optional pre-proposal conference is scheduled for all prospective Proposers as follows: 


DATE: October 19, 2016 


TIME: 12:30 p.m. 


PLACE: Travis County Purchasing Office 


(a) 


(b) 


(c) 


Large Conference Room 
700 Lavaca, Suite 800 
Austin, Texas 78751 


Proposers are encouraged to attend the pre-proposal conference and make their attendance a 
matter of record by completing a sign-in roster identifying the prospective Proposer, name, and 
title of their attending representative. 


The purpose of the pre-proposal conference is to insure: 
(i) Proposers have a clear understanding of County needs; 


(11) the accuracy of specifications, descriptions, and solicitation terms, conditions, 
and documents; 


(1)  Proposers have an opportunity to identify any problems that might hinder or 
prevent the County from obtaining the proper services or equipment/supplies at 
a fair and reasonable price, as well as any issues that may inhibit a fair and 
accurate solicitation or restrict competition. 


Proposers having questions concerning the RFP document shall submit them in writing to the 
County Purchasing Agent at the address shown on Page 1 of this solicitation. Questions shall 
be submitted not later than one week preceding the date set for the pre-proposal conference so 
that appropriate information may be researched and made available during the pre-proposal 
conference to all concerned. 


Any changes resulting from the pre-proposal conference that affect specifications or the scope 
of work, or that may require an extension to the bid opening date, will be reduced to writing in 
the form of an amendment to this solicitation. Such amendment will be distributed to all 
prospective Proposers. 


LATE PROPOSALS OR MODIFICATIONS: 
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Proposals and modifications received after the time set for the proposal submission will not be 
considered. 
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10.0 


WITHDRAWAL OF PROPOSALS: 


A proposal may not be withdrawn by the Proposer without the permission of Travis County for a 
period of one hundred and eighty (180) calendar days following the date designated for the receipt of 
proposals, and Proposers agree to this by submitting a proposal. 


POINTS OF CONTACT: 


Information regarding the purchasing process, the contents of this RFP, or questions concerning the 
technical requirements in Part II may be obtained from Lori Clyde, Purchasing Agent Assistant IV, 
Travis County Purchasing Office, 700 Lavaca, Suite 800, Austin, Texas, at telephone (512) 854-4205. 
Mention the RFP number at the top of this page. 


CLARIFICATION OR OBJECTION TO PROPOSAL SPECIFICATION: 


If any person contemplating submitting a proposal for this contract is in doubt as to the true meaning 
of the specifications or other documents or any part thereof, he/she may submit to the Purchasing 
Agent on or before TEN (10) DAYS PRIOR to scheduled opening a request for clarification. All such 
requests shall be made in writing and the person submitting the request will be responsible for its 
prompt delivery. Any interpretation of the RFP will be made only by RFP Amendment duly issued. In 
addition to being posted on BidSync, a copy of such RFP Amendment will be mailed or faxed to each 
person receiving a solicitation who does not have access to electronic means of doing business. 


GENERAL CONDITIONS: 


Proposer shall thoroughly examine the specific requirements, schedules, instructions and all other 
contract documents. Proposals must set forth accurate and complete information as required by this 
RFP (including attachments). No plea of ignorance by the Proposer of conditions that exist or that 
may hereafter exist as a result of failure or omission on the part of the Proposer to make the necessary 
examinations and investigations, or failure to fulfill in every detail the requirements of the contract 
documents, will be accepted as a basis for varying the requirements of Travis County or the 
compensation to the Proposer. 


By submitting a proposal, the Proposer warrants that he/she is fully satisfied that these specifications, 
as amended if applicable, accurately describe or indicate that all conditions have been taken into 
account in determining the offered price(s). There will be no increase in the contract price based upon 
Proposer’s misunderstanding or lack of knowledge about the intent of this solicitation. 


ETHICS POLICY: 


10.1 County has adopted an Ethics Policy that controls the way in which County contracts with 
vendors who have entered into certain transactions with persons who are influential in selecting 
vendors for a particular contract and in determining the terms and conditions of the contract. 
The persons that the County considers to be influential in this contract are called Key 
Contracting Persons and are listed in the Exhibit A to the Affidavit at the end of Part I. 
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This policy requires Proposers to inform Travis County of covered transactions with the Key 
Contracting Persons that have occurred in the year before they submit their proposals and to 
swear and submit the affidavit at the end of this section with their proposal. The transactions 
that are covered by the Ethics Policy are those described in Section 23.0 of Part IV of this RFP. 
This policy also requires the selected Proposer to inform County of covered transactions with 
the Key Contracting Persons that occur at any time during the Contract term. If the selected 
Proposer does not comply with these information requirements, the selected Proposer must 
continue to perform the contract and forfeit all of the benefits of the contract as provided in 
Section 23.0 of Part IV of this RFP. 


CERTIFICATE OF INTERESTED PARTIES: 

In 2015, the Texas Legislature adopted House Bill 1295, which added section 2252.908 of the 
Government Code. The law states that a governmental entity or state agency may not enter into 
certain contracts with a business entity unless the business entity submits a disclosure of interested 
parties form to the governmental entity or state agency at the time the business entity submits the 
signed contract to the governmental entity or state agency. The form discloses any interested parties 
who have a controlling interest (10% or more ownership) in the business entity and those who actively 
participate in facilitating the contract or negotiate the terms of the contract (broker, intermediary, 
advisor, and/or attorney), if any. The disclosure requirement applies to a contract entered into on or 
after January 1, 2016. 


The Texas Ethics Commission was required to adopt rules necessary to implement that law, prescribe 
the disclosure of interested parties form, and post a copy of the form on the commission’s website. 
The commission adopted the Certificate of Interested Parties form (Form 1295) on October 5, 2015 
and new rules (Chapter 46) on November 30, 2015. 


Filing Process: 
Vendors who are awarded contracts requiring an action or vote by the Travis County Commissioners 
Court for goods or services in an amount of $50,000 or more, or any contract in the amount of $1 


million or more, will be required to submit a signed and notarized Form 1295. Please follow the 
process to create a Form 1295 from the Texas Ethics Commission’s website at: 


https://www.ethics.state.tx.us/whatsnew/elf_info_form1295.htm 
14 The “identification number” to be used on Form 1295 for this procurement is: P1609-008-LC 


1.2 The completed and notarized form must be submitted to the Travis County Purchasing Office 
before a purchase order is issued or a contract is signed. 
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1.0 


2.0 


PART I, SECTION B -REQUIRED DOCUMENTATION 


The following documentation must be submitted with the proposal. Paragraph 2.0 describes 
documentation that will be used in the evaluation of the Proposer’s proposal. Paragraph 3.0 lists other 
documents that must be submitted. Please note this Section B may not address all documentation 
required by this RFP. The Proposer is cautioned to read the entire RFP to determine all 
requirements. TRAVIS COUNTY RESERVES THE RIGHT TO REJECT A PROPOSAL 
THAT DOES NOT CONTAIN ALL INFORMATION REQUIRED BY THIS RFP. 


To achieve a uniform review process and to obtain a maximum degree of comparability, Travis 
County requires that proposals be submitted with a master (marked “Original”) and five (5) copies 
(marked “Copy”). They are to include the following: 


2.1 Title Page 


Title page must show the RFP subject; the Proposer’s name; the name, address, and telephone 
number of a contact person; and the date of the proposal. 


2.2 Table of Contents 


Both physical and electronic versions should include a Table of Contents. In the electronic 
version the Table of Contents must be linked to each section for ease of navigation. Physical 
form must be in a 3-ring binder, with tabs dividing the sections. 


2.3 Transmittal Letter/Executive Summary 


Submit a signed letter briefly addressing the Proposer’s understanding of the work to be done, 
the commitment to do the work detailed within this RFP and a statement explaining why the 
Proposer believes it is best qualified to do the required work. 


2.3 Detailed Proposal 


The detailed proposal must address the ability to provide equipment and services for each 
requirement as set forth in Parts I through IV of this RFP. See especially Part I, Section C, 
Evaluation factors for information required. 


2.4 Cost Proposal (Attachment 11Error! Reference source not found.) 


This portion of your proposal contains the cost for your proposed Element(s). All Proposers 
shall complete Error! Reference source not found. 11. The Proposer is responsible for 
verifying that their cost submission is complete and accurate. 


2.5 Proposer References 


The Proposer must furnish at least three (3) references similar to County for which the 
Proposer has provided similar goods or services within the last five (5) years. These references 
must include (a) a description of the services and location of the contract and (b) the name, 
address, telephone number and email address of at least one (1) person that represents the 
Proposer’s customer. Travis County may contact or visit any of the listed customers to evaluate 
the services proposed in response to this RFP. (See Qualifications Questionnaire, Item 12.) 
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3.0 


2.6 


Ze 


2.8 


Description of Proposer 


The description must include the full legal name of Proposer, a description of the goods and/or 
services Proposer provides, the number of Proposer’s employees , description and location of 
Proposer’s facilities where work will be performed for this RFP when not onsite, and a 
description of Proposer’s entity status. (See Qualifications Questionnaire). 


Description of Typical Engagements 


Describe Proposer’s principal area of business practice and revenue generation. Provide an 
executive level overview of Proposer’s project management, product development practices or 
services engagement that supports the Element(s) Proposer is proposing to provide. 


Proposer Representative 


Include the name of the designated individual(s), along with respective telephone numbers, 
who will be responsible for answering technical, functional, and contractual questions with 
respect to the proposal. 


Proposer must submit the following documents with the proposal: 


o ls 


3:27 


3.3* 


3.4 


3.5 


3.6 


Ethics Affidavit (and Exhibits “A” and “B”) 
HUB Program Subcontracting Declaration 
Qualifications Questionnaire; Firm Experience and Qualifications 


Attachment 10 - Insurance documentation within ten (10) calendar days after award and before 
beginning work 


Attachment 11 — Schedule of Items (submit the original in an envelope separate from RFP 
response and on the flash drive save as a separate file from the RFP response entitled 
“Attachment 11 Schedule of Items”) 


All other information required in this RFP 


* These documents are included as attachments to this Part I, Section B. 


NOTE: 


FAILURE TO PROVIDE ALL INFORMATION REQUESTED MAY RESULT IN 
DISQUALIFICATION OF THE PROPOSAL. 
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STATE OF TEXAS} 
COUNTY OF TRAVIS} 


ETHICS AFFIDAVIT 


Date: 

Name of Affiant: 

Title of Affiant: 

Business Name of Proposer: 
County of Proposer: 


Affiant on oath swears that the following statements are true: 

1. Affiant is authorized by Proposer to make this affidavit for Proposer. 
Ze Affiant is fully aware of the facts stated in this affidavit. 

3. Affiant can read the English language. 


4, Proposer has received the list of key contracting persons associated with this solicitation which is 
attached to this affidavit as Exhibit A. 


J: Affiant has personally read Exhibit A to this Affidavit. 
6. Affiant has no knowledge of any Key Contracting Person on Exhibit "A" with whom Proposer is doing 


business or has done business during the 365 day period immediately before the date of this affidavit 
whose name is not disclosed in Exhibit “B” to this Affidavit. 


Signature of Affiant 


Address 


SUBSCRIBED AND SWORN TO before me by on ,20__ 


Notary Public, State of _ 


Typed or printed name of notary 
My commission expires: 
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EXHIBIT A 
LIST OF KEY CONTRACTING PERSONS 
September 14, 2016 


CURRENT 
Name of Individual Name of Business 

Position Held Holding Office/Position Individual is Associated 

County Judges: incendie anni dali nne Sarah Eckhardt 

County Judge (Spouse) ..oooococcnccnonnnoconononancnnnconcconocnnos Kurt Sauer Kelly Hart LLP 

Chief0f tallo conc ansias Peter Einhorn 

Executive Assistant ..ooooonocononconnnoncnonnncnnnnncnncconoconocnnos Loretta Farb 

Executive Assistant 00.0... cece eeeeeeceeeceseenseeeseenaes Joe Hon 

Executive Assistant ..........escceescecsseceeececeseceeeeecseeenees Maya Reisman 

Commissioner, Precinct 1 .......oonooononncnncononocanononncnonnns Ron Davis 

Commissioner, Precinct 1 (Spouse) ............ eee Annie Davis Seton Hospital 

Executive Assistant ..ooooconocononcocncononononancnnncnncconocnnocnnos Deone Wilhite 

Executive Assistant ..ooooccnoconnnconnnononononancnnncnnnconoconocnnos Felicitas Chavez 

Executive Assistant 0.0.0... eee eee eeceeeceseceseceseenseenees Sue Spears 

Commissioner, Precinct 20... eee ee eeeeeseceseceeeees Brigid Shea 

Commissioner, Precinct 2 (Spouse) .......... eee John Umphress Austin Energy 

Executive Assistant sesi cee eecescesecesecssecseeeneeeneeees Barbara Rush 

Executive Assistant issii cece eecessceseceseceeesseenaes Kristian Caballero 

Executive Assistant 2.0.0... cscescecsseceeeeecsseceeneeesaeeeenees Melissa Velasquez 

Commissioner, Precinct 3.0... eee eeeeeeeseceseeeseeeees Gerald Daugherty 

Commissioner, Precinct 3 (Spouse) .......... eee Charyln Daugherty Consultant 

Executive Assistant 0.0.0... eecseecessceseceeceseesseenees Bob Moore 

Executive Assistant ..ooooococcconnconnocnnonnnonnconoco nono nocnnccnnos Martin Zamzow 

Executive ASSIStAHi. ner e e Madison A. Gessner 

Commissioner, Precinct 4.0... eee ee eeceeeceteeeeeees Margaret Gomez 

Executive Assistant 0.0... eeeeeeceeseeseeeseenseenaes Edith Moreida 

Executive: Assistant sisis isisisi ree sereis erosa i sisir Norma Guerra 

County TreasuUrer...ooconcononcononinnnonnnorncnrnanonon neon ne rnnc ones] Dolores Ortega-Carter 

AAA ssrin Nicki Riley 

County Human Resources Interim .....ooonnnnnnnninnnncc... Todd L. Osburn* 

County Executive, Administrative ......... ee Vacant 

County Executive, Planning & Budget we. Jessica Rio 

County Executive, Emergency Services „r... Danny Hobby 

County Executive, Health/Human Services .............. Sherri E. Fleming 

County Executive, TNR ........ccceesseecceessseeeneecseeeenees Steven M. Manilla, P.E. 

County Executive, Justice & Public Safety ............... Roger Jefferies 

Director, Facilities Management... eee eee Roger El Khoury, M.S., P.E. 

Chief Information Officer ....ooooononnconncnconnnonaconoconocnnos Tanya Acevedo 

Director, Records Mgment & Communications........ Steven Broberg 

Travis County Attorney cooooccccconnccnnónnocnnonnconcconoconocnnos David Escamilla 

First Assistant County Attorney esseere Steve Capelle 

Executive Assistant, County Attorney .......... James Collins 

Director, Land Use Division .....ooooccnncnononononanononicnnnnns Tom Nuckols 

Attorney, Land Use Division 00.0.0... eee eee eeeeeeeee Julie Joe 

Attorney, Land Use Division 00.0.0... eee ee eeeeeeeeeee Christopher Gilmore 

Director, Transactions Division .......cccconncocnnnncnnnnnnnos John Hille 

Attorney, Transactions Division... C.J. Brandt* 

Attorney, Transactions Division..........0.. eee eee Ann-Marie Sheely 

Attorney, Transactions Division............scesseeeeeeeeees Barbara Wilson 

Attorney, Transactions Division..........0.. eee eee Jennifer Kraber 

Attorney, Transactions Division.............:ceesceeeseeeeees Tenley Aldredge 

Director, Health Services Division.........0... eee Beth Devery 

Attorney, Health Services Division.........0..... eee Elizabeth Winn 

Attorney, Health Services Division........0... eee K. Nicole Aquino* 

Attorney, Health Services Division........0000 eee Prema Gregerson 

Attorney, Health Services Division........0..... eee Barbara E. Misle 


Attorney, Health Services Division...........c:eeeeeeees Ruben Baeza, Jr. 
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Attorney, Health Services Division........00.0. eee Holly Gummert* 

Purchasing Agent c.oococononnnoncnnnnoncnononancnnncnncconocnnocnnos Cyd Grimes, C.P.M., CPPO 

Assistant Purchasing Agent... eee eeeeeeeeeeeeeeeees Elaine Casas, J.D. 

Assistant Purchasing Agent ..oooooccnccnncnnonnconnconoconocnnos Marvin Brice, CPPB 

Assistant Purchasing Agent...........cceccecsscceeeeeeeeeeeenees Bonnie Floyd, CPPO, CPPB 

Purchasing Agent Assistant IV „oaeee CW Bruner, CTP, CPPB 

Purchasing Agent Assistant IV ........e ce ceeeeeeeeeeeeeeeeees Lee Perry 

Purchasing Agent Assistant IV „oaeee Jason Walker 

Purchasing Agent Assistant IV „osese Patrick Strittmatter, CPPB 

Purchasing Agent Assistant IV „oaeee Lori Clyde, CPPO, CPPB, CTPE 

Purchasing Agent Assistant IV „s.es Scott Wilson, CPPB 

Purchasing Agent Assistant IV s.es Jorge Talavera, CPPO, CPPB 

Purchasing Agent Assistant IV ..ooooncccnnncccoccccnonacinnos Loren Breland, CPPB 

Purchasing Agent Assistant IV „oaeee John E. Pena, CTPM, CPPB 

Purchasing Agent Assistant IV ..o.oooonnccnnnccccccccconcconnos Kimberly Roohms 

Purchasing Agent Assistant IV „oaeee Jonathan Harris* 

Purchasing Agent Assistant IV .ooooocncccnnnccnonacinoncconnno Veronica Frederick* 

Purchasing Agent Assistant TID... ee eeeeeeeeeeeeeee Logan Brown, CTCM, CTPM* 

Purchasing Agent Assistant TD... ee eeeeeeeeeeeeeeeee David Walch 

Purchasing Agent Assistant IID... eee eee Jean Liburd 

Purchasing Agent Assistant IT... Sydney Ceder 

Purchasing Agent Assistant TD... eee eeeeeeeeeeeeneee Ruena Victorino 

Purchasing Agent Assistant TD... eee eeeeeeeeeeeeeeee Rachel Fishback 

Purchasing Agent Assistant I]... eeeceeeeeeeeeeeeees L. Wade Laursen 

Purchasing Agent Assistant ID... eee eeeeeeeeee Sam Francis 

HUB Coordinator ..cccconooooononocononononnnnnnonononnnnononccncnnnnns Allen J. Roberts, MBA, CTP* 

HUB Specialists sss: ss.5 cosessscsvias es skpes eae Trie Betty Chapa 

HUB Specialists isisisi series Jerome Guerrero 

HUB Specialist sics iTr Paula Ann Pitifer 

Purchasing Business Analyst ...ooooonccnccniccconcconcconocnnos Scott Worthington 

Purchasing Business Analyst „s.src Rosalinda Garcia 

County Clerk A eri ea Dana DeBeauvoir 

County Clerk’s Office .....oooooocnonoconocoononacancnncnonanocnnnnos Ron Morgan 

County Clerk’s Office ....ooocooocnonoccnocccccnncancnncnonononnnnnos Scott Flom 

County Clerk’s Office .....oooooocnonnccnoncononacancnncnonadoóncnnos Candi Semple 

County Clerk’s Office .....oooooocnonoccnoncnncnncanconénacononnnonos Michael Winn 

County Clerk’s Office ....ooooooconccoccnocacononcaconacancnncnnnnnos Geetha Lingham 

Consultant/Project Director .....oooocnnncnncónncnconnconncnnacnnos Neil McClure 

Project Consultant ...ooooccnncnnonconnnoncninnnccnnncconacanecnocnnos Bryce Eakin 

Project Consultant ...oooooconocononconncononocnnnncaneconaconccnnncnnos Susan Bell 

Technical Consultadt....oooooonnnoncnonnnaninacononcnanconocnocnnos Dan Wallach, Rice University 

Technical Consultant... ccc eeceeecesseeseeeeeees Neil McBurnett 

Technical Consultadt..........ccccconnooonnnnccnnonnnocononcnncnnnnns Olivier Pereria, UC Louvain, Belgium 
Technical Consultant..............cccccsccccccecesssssceceeeceenens Ronald Rivest, MIT 

Technical Consultadt.....ooooononnconononaconococonnnonnnonocncnonnns Josh Benaloh, Microsoft, Inc. 

Technical Consultant... elie eeceeeceseenseeaes Mike Byrne, Rice University 

Technical Consultant... ee eeeceeeceeeeeseeeeeeaes Phil Kortum, Rice University 

Technical Consultadt....ooocnnnnnoncnonnnoncnoncnnnconoconoconocnnos Philip Stark, UC-Berkeley 

Election Study Group... eee eceeceesceeeeeseeneeeaes Nan Clayton, Texas League of Women Voters 
Election Study Group .cocccocconccononononononancnncnncconoconocnnos Alcia DelRio, Austin Community College 
Election Study Group ..ocoooccoccconccononononancnnnconoconoconocnnos Arthur De Bianca, Travis County Libertarian Party 
Election Study Group ..oooooccoccconccononononancnnnconoconoconocnnos Maria Jimenez, Presiding Judge — Democratic Party 
Election Study Group ..ooooocccccconccononanononcnnncnncc noc nocnnos Jannette Goodall, City of Austin 

Election Study Group ..ocooocccccconccononanonancnncconoconoconocnnos Sherri Greenberg, LBJ School of Public Affairs 
Election Study Group ..ocoooccconconcconononcnancnnnconoconoconocnnos Zoe Griffith, Austin ISD 

Election Study Group ..oooocccocncocnccncnoncnnnconoconocanocnnocnnos Jim Henson, UT Department of Government 
Election Study Group ..oococccocccocnccnnnonnnnnconoconoconocnnccnnos Reuben Leslie, Travis County Democratic Party 
Election Study Group ..oococccocccocnncnononcnancnnnconoconocnnocnnos Ron Lucey, Austin Mayor’s Committee for People with Disabilities 
Election Study Group ..ocooocconccocnnccnonnnnancnnnconocnocnnocnnos Lorenzo Sadun, UT Department of Mathmatics 
Election Study Group ..ocooccconncocnccnnonnnonnconoconocnnoconocnnos James Dickey, Chair, Travis County Republican Party 
Election Study Group ..oocoocconncocnncnonononancnnncnoconocnnccnnos May Schmidt, Early Voting Deputy 


Election Study Group ..oooocccocccccnncnnnoncoanconoconocnocnnocnnos Bill Stout, Green Party of Texas 
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Election Study Group ..oococcconconcnononanonancnnncnnnconcconocnnos Robert Sheldon, Election Day Judge 

Election Study Group ..oooooccoccconccononononancnnncnnnconocnocnnos Vincent Harding, Chair, Travis County Democratic Party 

Election Study Group ..occoocconcconononononononcnnncnncconoconocnnos Karen Renick, VoteRescue 

Election Study Group ..ooococcocnconnnonononononcnnnconoconoconocnnos Daniel Biering, Election Judge 

Election Study Group ..ocoooccccnconcnonononononcnncnncconocnnocnnos Mike Conwell, Election Judge/Political Activist 

Election Study Group ..ooococcccnconnnononononancnnncnncconoconocnnos Wilhelmena DeMarco, Former State Representative 

Election Study Group ..ooococcccnconcconononononcnancnncconoconocnnos Susan DeMarco 

Election Study Group ..ooococcccnconcnoncnononancnnnonnnconccnnocnnos Jim McNabb, Retired Journalist 

Election Study Group ..ooococccccconnnoncnanonancnnnconoconoconocnnos Madeline Perasall, Political Candidate 

Election Study Group ..ooococcccnconnnoncnononancnnncnnncanocnocnnos Sabine Romero, Attorney, City of Austin 
FORMER EMPLOYEES 

Name of Individual 

Position Held Holding Office/Position Date of Expiration 
Attorney, Health Services Division ...........cseeseeeeseeees Randy M. Floyd.. oc. oocconccononn orere pA 10/03/16 
Purchasing Agent Assistant IV ......... cc eeeeeseeceereeeneeees Richard Villareal... eee eeee coonocnnccnno 10/31/16 
Purchasing Agent Assistant TD... ee eeseeeeereeeneeees Anthony Webb ... coooonccnino oocconocononn apere Eoo 02/05/17 
Purchasing Agent Assistant IV ......... cc eeeeeseeeeereeeneeees Jesse o A A 03/04/17 
County Human Resources ..oooooccnoconocconnconoconocanocnonanonn Debbie Maynor... cooccconccono oocoonccnneno oonnrancnnnono 03/17/17 
Attorney, Transactions DIVISION.....coococnononcncccnonnnconccono Daniel Bradford .. oo... oocconccnnóno oonoronnnnnono 06/01/17 
HUB Coordinator stipes ias sairis Sylvia Lopez... cece cee eee Me 07/31/17 


* - Identifies employees who have been in that position less than a year. 
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EXHIBIT B 
DISCLOSURE 
Proposer acknowledges that Proposer is doing business or has done business during the 365-day period 


immediately prior to the date on which this proposal is due with the following Key Contracting Persons and 
warrants that these are the only such Key Contracting Persons: 


If no one is listed above, Proposer warrants that Proposer is not doing business and has not done 
business during the 365-day period immediately prior to the date on which this proposal is due with any key 
contracting person. 
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Assigned Contract #: 
(For County Office Use Only) 


HISTORICALLY UNDERUTILIZED BUSINESS (HUB) PROGRAM SUBCONTRACTING DECLARATION 


SAI NNABIDDER AND SOLICITATION INFORMATION 


Bidder Company Name: 
Project Name: Total Bid Amount: 


Is your company a certified HUB? 
Certifying Agency (Check all applicable): L] State of Texas (HUA [_] City of Austin L_] Texas Unified Certification Program 
eee [neg 


Definitions: 


HUB - Historically Underutilized Business = M/WBE - Minority/Women-Owned Business Enterprise = DBE — Disadvantage Business Enterprise 


The policy of the Travis County Purchasing Office is to ensure a “Good Faith Effort” (GFE) is made to assist certified HUB vendors and contractors i 
receiving contracts in accordance with the HUB Program policies and the Minority and Woman-owned Business (M/WBE) goals adopted by the Trav 
County Commissioners Court. Travis County encourages all Bidders to register as a County vendor through the County's online vendor registration. 


*Prime Contractors who are awarded contracts with the County are required to make a “Good Faith Effort” to subcontract with HUBs. This includes 
professional services associated with the projects. 


leg iie)\PASUBCONTRACTING INTENTIONS 


Percentage to be subcontracted to Certified HUBs: 


Total MBE Dollars: Total MBE Percentage: Total WBE Dollars: Total WBE Percentage: 


Check the box that applies to the Bidder: 


C] We are able to fulfill all subcontracting opportunities with our own resources. If circumstances necessitate the use of any subs, | agree to seek 
the timely authorization by the County and adhere to the submission of any required documentation. (Complete Sections 5, 6 and 8) 


L] We plan to subcontract some or most of the opportunities of this project and meet or exceed the set goals. (Complete Sections 3, 4, 6 and 8) 


C] We plan to utilize subcontractors on this project, but will not meet the set goals. (Complete Sections 3, 4, 5, 6 and 8) 


The HUB Program policies and Minority and Woman-Owned Business subcontracting goals shall be applicable to the eligible procurement dollars 
spent in the areas of Construction, Commodities, Services, and Professional Services. 


><] COMMODITIES Overall MBE Goal: 3.5% Sub-goals: Overall WBE Goal: 6.2% 
0.3% African-American 
2.5% Hispanic 

0.7% Asian/Native-American 
[L] CONSTRUCTION Overall MBE Goal: 13.7% Sub-goals: Overall WBE Goal: 13.8% 
1.7% African-American 
9.7% Hispanic 

2.3% Asian/Native-American 
L SERVICES Overall MBE Goal: 14.1% Sub-goals: Overall WBE Goal: 15.0% 
2.5% African-American 
9.9% Hispanic 

1.7% Asian/Native-American 
[_] PROFESSIONAL SERVICES Overall MBE Goal: 15.8% Sub-goals: Overall WBE Goal: 15.8% 
1.9% African-American 
9.0% Hispanic 

4.9% Asian/Native-American 
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¡Jl Ky DISCLOSURE OF CERTIFIED HUB SUBCONTRACTORS (Duplicate as necessary) 


Travis County exercises the right to verify subcontractors listed on this project. It is the County’s practice to consider ethnicity before gender when 
distinguishing HUB certifications and calculating goal achievement. 


Note: To be considered “certified” with the State of Texas, City of Austin or the Texas Unified Certification Program, please attach a current and valid 
certificate. Sub-goals are included to assist you in diversifying your subcontractors. 


Sub Company Name: State of Texas VID#: 


Address: City: State: Zip Code: 


Subcontract Amount: Description of Work: 


Is your company a certified HUB? 
O Yes C No Indicate Gender & Ethnicity: 


Certifying Agency (Check all applicable): LJ State of Texas (HUB) | [_] City of Austin] [_] Texas Unified Certification Program 
(M/WBE) (TUCP) (DBE) 


Sub Company Name: | State of Texas VID#: = of Texas VID#: 


Subcontract Amount: Description of Work: 


Is your company a certified HUB? 
O Yes [] No Indicate Gender & Ethnicity: 


Certifying Agency (Check all applicable): L] State of Texas (HUB) | [_] City of Austin] [_] Texas Unified Certification Program 
(M/WBE) (TUCP) (DBE) 


Sub Company Name: State of Texas VID#: 


Subcontract Amount: Description of Work: 


Is your company a certified HUB? 
Certifying Agency (Check all applicable) LJ State of Texas (HUB) | [_] City of Austin E Texas Unified Certification Program 
ugyen — ita (a 


Sub Company Name: | State of Texas VID#: aaa of Texas VID#: 
Address: eS A Code: 


Subcontract Amount: Description of Work: 


Is your company a certified HUB? 
O Yes []No Indicate Gender & Ethnicity: 


Certifying Agency (Check all applicable): LJ State of Texas (HUB) | [_] City of Austin] [_] Texas Unified Certification Program 
(M/WBE) (TUCP) (DBE) 
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ZILOK DISCLOSURE OF NON-HUB SUBCONTRACTORS (Duplicate as necessary) 


Travis County exercises the right to verify subcontractors listed on this project. 


Sub Company Name: State of Texas VID#: 


Subcontract Amount: Description of Work: 


Sub Company Name: State of Texas VID#: 


Subcontract Amount: Description of Work: 


Sub Company Name: State of Texas VID#: 
Subcontract Amount: Description of Work: 
Sub Company Name: State of Texas VID#: 
Subcontract Amount: Description of Work: 


eg (ee NON-COMPLIANT FOR MEETING SET HUB GOALS CHECKLIST 
If you were unable to meet the set goals for this project, select the box by the response(s) that best fits your situation. 
C] All subs to be utilized are “Non-HUBs.” L] HUBs solicited did not respond. 


C] HUBs solicited were not competitive. C] HUBs were unavailable for the following trade(s): 


{eg le) DETERMINATION OF “GOOD FAITH EFFORT” (GFE) CHECKLIST 


The following checklist shall be completed by the Bidder and returned with the response. This list contains the minimum efforts that should be put forth by 
the Bidder when attempting to achieve or exceed the HUB goals. The Bidder may go beyond the efforts listed below. If additional information is needed, 
the Bidder will be contacted by the HUB Program Staff. Select the box that describes your efforts. 


C] Divide the contract work into the smallest feasible portions to allow for maximum HUB Subcontractor participation, consistent with standard and prudent 
industry practices. 


L Notify HUBs of work that the prime contractor plans to subcontract, allowing sufficient time for effective participation? 
The HUB Program encourages that three or more HUBs be notified per scope of work and given no less than five working days to respond. 
(The notification should contain adequate information about the project i.e. plans, specifications, and scope of work; Bonding and insurance 
requirements of the HUB subcontractor; and a point of contact within the Bidders organization.) 


O If a bid was requested from a HUB and then rejected, was a written rejection notice detailing the reasons why they were not selected issued? 
If yes, provide a copy of the rejection letter. 


O Provide notices of opportunities to minority or women trade organizations or development centers to assist in identifying potential HUBs by disseminating 
the information to their members/participants? If yes, attach correspondence. 


O Bidder has (0) zero HUB participation. Provide an explanation 
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¡09 [0] NARESOURCES 
TRADE ASSOCIATIONS 
Asian Construction Trade 


Austin Black Contractors 


Austin Metropolitan United Black Contractors 


Natl. Assoc. of Women in Construction 
US Hispanic Cont. Assoc. de Austin 


CERTIFYING AGENCIES TRAVIS COUNTY RECOGNIZES 


State of Texas Centralized Master Bidders List 
City of Austin Minority Vendor Database 


Texas Unified Certification Program 


EI NEJAFFIRMATION 
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926-5400 926-5410 


784-1891 255-1451 unism@sbcqlobal.net 
a 


CERTIFYING AGENCIES 
VENDOR DATABASE WEBSITES 
www.cpa.state.tx.us/business.html CMBL includes 
certified HUBs. 


www.austintexas.gov/department/small-and- Certified Vendors 
minority-business Directory 


www.dot.state.tx.us/business TUCP DBE Directory 


PHONE (512) E-mail/website 


As evidenced by my signature below, | certify that all the information provided is correct to the best of my knowledge. | am an authorized 
representative of the Bidder listed in SECTION 1, and that the information and supporting documentation submitted with HUB Forms are correct and 


true to the best of my knowledge. 


Bidder understands and agrees that, if awarded any portion of the solicitation: 


= The Bidder must either utilize Travis County HUB Programs Vendor Tracking System (VTS) to report payments to sub- 
contractors on a monthly basis or submit monthly Payment Reports as requested by the HUB Program Coordinator. 


The Bidder must seek pre-approval from the HUB Program Coordinator prior to making any modifications to their HUB Sub- 
contracting Plan. The Bidder must complete a HUB Subcontractor/Subconsultant Change Form obtained from the HUB Program 
Staff. Return form via fax to 512-854-9185 or email hubstaff@co.travis.tx.us. 


Travis County HUB Program Staff will perform a Good Faith Effort (GFE) Review, documenting the efforts put forth by the Bidder. 


Name and Title: 


Date: 


E-mail Address: 


Signature: 


Provide contact information for the individual in your office who will handle invoicing for this project: 


Name and Title: 


E-mail Address: 


Phone No.: 


Fax No.: 


Please be reminded that Travis County is not party to your agreement executed with the subcontractors and subconsultants. 


QUALIFICATIONS QUESTIONNAIRE 
This questionnaire is to be completed in its entirety. No modifications to the wording is permitted. 
Proposals submitted with Qualifications Questionnaires that are incomplete or incorrect, or that have 


been altered, are subject to rejection. 


1. Name of Firm: 


2. Address of Headquarters: 


3. Address of Local Office If Different: 


4. Date of Organization (Month/Year) 


5. Names And Dates of Predecessor Organization (s): 


6. Type of Organization: 
Individual, Partnership, Association, Corporation, or other form 


7. Business Telephone and Fax Number (s): 


8. List of Principals, Titles, Degrees: 


FIRM EXPERIENCE AND QUALIFICATIONS 


9. Years of Experience - Number of years performing proposed services: 


10. Firm experience - Briefly describe three or more projects of similar content for each of the 
Elements contained in your proposal and include approximate duration and dollar value of the 


projects. 


Table 1: Projects illustrating firm's relevant experience 


Duration 


a Project Description 
of Project 


Dollar Value 


11. Project References - Describe at least three projects for each Element your proposal includes on 


which the firm has provided similar products or services within the last five years. 


description of the products or services, location of project, and the name, address, and telephone 
number of at least one person representing the client who received the products or services. 
proposing more than one Element, add additional tables as required. 


Table 4: Project Reference #1 


Location: Date(s) of Work: 


Description of Goods and Services: 


Reference Contact Information: 


Company Name: 


Contact Full Name: 


Contact Mailing Address: 


Contact Email Address: 


Contract Telephone Number 


Table 4: Project Reference #2 


Location: Date(s) of Work: 


Description of Goods and Services: 


Reference Contact Information: 


Company Name: 


Contact Full Name: 


Contact Mailing Address: 


Contact Email Address: 


Contract Telephone Number 


Table 4: Project Reference #3 


Location: Date(s) of Work: 


Description of Goods and Services: 


Reference Contact Information: 


Contact Full Name: 


Contact Mailing Address: 


Contact Email Address: 


Contract Telephone Number 


12. Attach a Management Chart showing the Project team members, areas of responsibility, and team 
organization structure. 


13. Project Staff — List the name of the person who will be directly responsible for performance of the 
Project services and indicate the number of years of experience managing projects of similar size. 
Attach resume(s) describing specific related experience. 


Table 5: List of Project Staff 


Years of 


Name Position/Title . 
Experience 
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PART I, SECTION C - ADDITIONAL INFORMATION 
OBJECTIVE: 


The Travis County Purchasing Agent is requesting competitive proposals from qualified entities 
for a set of components and modules that, collectively, will result in the functional 
implementation of STAR-Vote™ as defined in this RFP. The components and modules are: 


e Element A: EAC-Certified Modules 

e Element B: In-Person Voting/Tabulation and Support Modules 
e Element C: Ballot Box/Scanner 

e Element D: Red Team Assurance 


e Element E: Human Factors Evaluation 


PRE-AWARD SURVEY: 


After proposal opening and prior to award, County reserves the right to make a pre-award 
survey of Proposer's facilities and equipment to be used in the performance of this work. 
Proposer agrees to allow all reasonable requests for inspection of such facilities with two (2) 
business days advance notice. Failure to allow an inspection shall be cause for rejection of 
proposal as non-responsive. County reserves the right to reject facilities or equipment as 
unacceptable for performance as a result of the pre-award survey. 


PROPOSAL DISCLOSURE: 


Proposals will be opened so as to avoid disclosure of the contents to competing Proposers. 
Proposals will be kept secret during the process of negotiation. However, all proposals will be 
open for public inspection after award. If identified by the Proposer, County will make 
reasonable efforts to protect information that qualifies as trade secrets and/or confidential 
information under the Texas Public Information Act. 


SELECTION CRITERIA/EVALUATION FACTORS: 


Travis County will consider several evaluation factors, of which price is only one. Proposers 
may offer/propose solutions which meet the “spirit” of the listed requirements, but should note 
that only the proposed solution/service that meets or most closely meets all of the specifications 
will be recommended for award. 


The selection process will be based on the responses to this RFP, and any 
interviews/demonstrations required to verify the ability of Proposer to provide the 
services/products proposed in response to this document, along with reference checks. 
Evaluation factors and associated point values are listed in order of importance: 


1 | Completeness of Proposal Relative to Requirements: 40% 
Part I— Contractor Qualifications 
Part II — Project Management 
Part II — Detailed Responses 

Part II — Contractor Requirements 
Part II — Contract Requirements 
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2 | Cost: 30% 
e =Total Purchase Cost 

e Per Hour Rate for Proposer’s Technical Resources 

e Per Hour Rate for Technical Management Resources 

e Hourly rate for County requested requirements change 


3 | Quality of Proposer Credentials, Technical Capabilities and Services: 20% 
e Performance History 

e Years of Experience 

e References 

e Demonstrated expertise, personnel proposed (resumes, qualifications) 
e Level Competence for the proposed Element(s) 


4 | Subjective Evaluation: 10% 


e Response exhibits overall understanding of the system 
e Response embodies overall system objectives 
e Response addresses future implementations 


METHOD OF AWARD: 


5.1 The award of the contracts shall be made to the responsible Proposer for each specific 
Element, whose proposal is determined to be the best evaluated offer for that Element 
resulting from negotiation, taking into consideration the relative importance of price and 
other evaluation factors set forth herein. 


5.2 Prompt payment discounts will not be considered in determining low proposals and 
making awards. 


5.3 In considering the proposals, Travis County reserves the right to select one or more 
responsible Proposers. 


5.4 Travis County reserves the right to award only a portion of the RFP or selected 
Elements. 
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PART I, SECTION D - NEGOTIATIONS 


NEGOTIATIONS: 


1.1 


1.2 


1.3 


1.4 


1.5 


1.6 


The Purchasing Agent shall supervise all negotiations. 


Discussions may be conducted only with responsible Proposers who submit proposals 
determined to be reasonably susceptible of being selected for award. All Proposers will 
be accorded fair and equal treatment with respect to any opportunity for discussion and 
revision of proposals. Revisions to proposals may be permitted after submission and 
before award for the purpose of obtaining best and final offers. 


Proposers may be required to submit additional data during the process of any 
negotiations. 


Travis County reserves the right to negotiate the price and any other term with the 
Proposers. 


Any oral negotiations must be confirmed in writing prior to award. 


The RFP contains several technical requirements whose final specification will be 
defined during negotiations between Proposers of separate Elements. All Proposers 
agree to participate in these technical negotiations in good faith with the understanding 
that failure to reach agreement between the parties can result in a Proposer being 
removed from further consideration for contract award. 


DEVIATIONS: 


Requirements stated in this RFP shall become part of the contract resulting from this RFP 
unless the Proposer requests a deviation. Any requests for deviations from these requirements 
must be specifically defined by the Proposer in the proposal. If accepted, the deviation shall 
become part of the contract. Travis County reserves the right to modify the requirements of this 


RFP. 


REJECTION OF PROPOSALS: 


3.1 


County expressly reserves the right to: 


3.1.1 waive any defect, irregularity or informality in any proposal; 
3.1.2reject or cancel any proposal or parts of any proposal; 
3.1.3award contracts to one or more Proposers; or 


3.1.4procure the services in whole or in part by other means. 
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PROTESTS: 


Protests before award must be submitted in writing to the Purchasing Agent not later than six 
(6) calendar days after proposal opening, and protests after award must be submitted within ten 
(10) calendar days after award by Commissioners Court. The Purchasing Agent shall rule on the 
protest in writing within ten (10) calendar days from date of receipt. Any appeal of the 
Purchasing Agent's decision must be made within ten (10) calendar days after receipt thereof 
and submitted to the Purchasing Agent, who shall present the matter for final resolution to the 
Commissioners Court. Appellant shall be notified of the time and place the appeal is to be heard 
by Commissioners Court and afforded an opportunity to present evidence in support of the 
appeal. 
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PART I, SECTION E - BACKGROUND and GENERAL INFORMATION 


BACKGROUND 


1.1 STAR-Vote™ Origin 


In 2002, Travis County moved from an aged optical-scan, central-count election system to the 
Hart Intercivic DRE and Ballot Now ballot-by-mail system. This system has functioned well 
over the years, and the County currently utilizes 1,725 eSlate voting stations, 355 Disabled 
Accessibility Units, 461 Judges Booth Controllers, 30 Demo Units, and 3 Ballot Now stations 
that include 2 high-speed scanners and 2 ballot printers. 


In preparation for the purchase of a new voting system, the Travis County Clerk (the “Clerk’’) 
convened a citizens group in 2009 to begin discussions regarding the type of voting system 
the community wanted for the future. This group is comprised of approximately 45 members 
representing broad, diverse segments of the community. A similar group was formed around 
1990 when the County moved from a punch-card system to optical scan and again around 
2000 when the County adopted a DRE system. 


The Travis County Clerk’s Elections Study Group spent many hours learning about topics 
such as: 


e The nuts and bolts of election administration; 

e How election systems function for By-Mail voting, Early Voting, Mobile Voting, 
Precinct-Based Election Day Voting, and Vote Centers; 

e The challenges of current federal and state certification processes — the extent to 
which they protect the voter, the extent to which they interfere with election 
integrity (e.g., by making effective audits unnecessarily difficult), and their 
effects on cost and competitiveness (they are costly, slow, and discourage 
innovation and market participation); 

e The problems associated with the current election system market, including 
secretive programming and design methods, vendors’ responses of “trust me” to 
the public when questions arise, disincentives in the market for vendors to update 
and improve their equipment, vendors’ decisions to not follow other technology 
models where prices decrease after a technology is in broader use or has become 
dated, and high maintenance charges that are required but yield little benefit; 

e The types of election problems and concerns encountered across the nation 
including security, court decisions, the difficulties of determining voter intent, 
and recounts; 

e Viewpoints from activists and academia on computer security, usability, and 
accessibility; and 

e The different types of voting systems that are available. 


The group also had in-depth discussions and demonstrations from vendors and users of DREs, 
voter-verifiable paper audit trail (VVPAT), optical scanning, digital scanning, and hand-count 
paper-ballot systems. These discussions were followed by an analysis of the purchasing and 
operating costs of these systems. 


At the end of the process, the Study Group determined that Travis County would best be 
served by a system that uses an electronic count and paper ballots. The group found that no 
system on the market meets the needs of Travis County, and directed the Clerk to secure a 
system that met the standards the group found important and underrepresented in existing 
systems — security; transparency; auditability; reliability; cost effectiveness; usability; 
accessibility; and use of high-quality, up-to-date software design with improved functionality. 


When the Travis County Clerk elections team took up this challenge, they found that counties 
across the nation were facing similar circumstances. To break through the gridlock that had 
election administrators, academics, and activists at odds with one another, the team challenged 
these groups to work with her to craft the requirements for a new system that could best 
answer everyone’s concerns. 


The County Clerk received support from across the country and was especially honored that a 
distinguished professor at Rice University’s Department of Computer Science agreed to join 
this effort and garner the help of some of the country’s most revered experts in computer 
security, statistics, and usability. 


In long sessions with frequently rambunctious discussions, a group of election administrators, 
usability experts, and computer and statistical academicians came together to forge the idea of 
STAR-Vote'M, A paper detailing the results of this effort was presented by the Rice 
University professor at the 2013 meeting combining the Electronic Voting Technology 
Workshop, the Workshop on Trustworthy Elections, and the USENIX Journal of Election 
Technology and Systems (EVT/WOTE/JETS). A copy of that paper can be found at: 


https://www.usenix.org/conference/evtwote 1 3/workshop-program/presentation/bell 


As interest grew and specific requirements for STAR-Vote™ became more defined, other 
counties began serious inquiries about participating in the process. At this point, the County 
Clerk decided to create and issue an initial RFI for gaining input into the STAR-Vote™ 
concept and further determining a plan for development and implementation. 


1.2 Demographics 


Austin, the State Capital, is located in Travis County. Travis County is in central Texas 
and is just over 1000 square miles. It has a population of over 1.063 million of which 623,000 
are registered voters. Austin, the proud capital of Texas, covers a vast area of Travis County 
and is surrounded by numerous smaller cities, towns, villages, and unincorporated areas. As a 
center for the State’s governmental activity, the community has a higher-than-average interest 
and understanding of politics and election issues. 


Travis County is the home of the University of Texas and Austin Community College. 
The University of Texas has over 50,000 enrolled students and Austin Community College 
follows with an enrollment of 40,000. Travis County is also home to other high quality 
learning institutions such as St. Edwards, Huston-Tillotson, and Concordia Universities. 


Austin and Travis County are growing rapidly. According to the Census Bureau, Austin 
had the fastest population growth in the United States in 2013. Surrounding cities within 30 
miles of Austin just outside of Travis County (San Marcos, Cedar Park, etc.) ranked among 
the top most rapidly growing cities with populations of 50,000 or more. 


Travis County features a diverse population. The area has become a majority-minority city, 
where no ethnic or demographic group has a majority of the population. Austin’s Anglo 
population dropped below 50% around 2005. Austin’s current Hispanic population is around 
35%. Growing the most rapidly is Austin’s Asian population. In 1990, it was around 3.3%, 
and it now stands at around 6.5%. It is important that all election related materials be offered 
in English and Spanish. We anticipate that in the near future, an Asian language will need to 
be incorporated. Delaying an immediate change is the uncertainty as to which Asian 
language(s) will best serve the voters. 


Travis County has a large number of young people. A 2014 report by the Community 
Advancement Network (CAN) reports that Travis County has a comparatively young 
population. About 76% of the population is over 18. 18% are between the ages of 25 to 34 
and only about 8% of the population is 65 years of age or older. 


Travis County has approximately 85,000 to 116,000 persons with disabilities. Estimates 
of the number of people with disabilities in Travis County vary between studies. This may 
have to do with how the term “disabled” is interpreted. Some sources show there are about 
85,000 individuals; others estimate the number to be about 11% of the population. Regardless 
of the exact count or definition, the Travis County Clerk’s Office has a long history of doing 
whatever is possible to provide accessible voting, create a voting experience that is the same 
or similar to that of everyone else, and give persons the right to a private vote. 


1.3 Election Data 


Travis County has 247 election precincts and over 120 political subdivisions. County 
elections encompass federal, state, and local races. In addition to County elections, the 
County Clerk offers election services to over 120 local jurisdictions, including: 

e Cities; 

e Acommunity college; 

e A transportation authority; and 

e School, utility, emergency service, library, and aquifer districts. 

The number of entities conducting an election on one date has varied from 2 to 35. Entities 
often have boundaries that do not follow election precinct lines and create a situation called 
“split precincts.” In addition, entities may have at-large races and/or district races. Each 
precinct and its unique configuration of elections and races constitute a precinct/ballot style. 
As a result, the number of different precinct/ballot styles generated for one election date has 
ranged from 250 to 850. The length of a ballot varies dramatically. Ballots in large elections 
have contained as many as 34 separate elections and included 154 races with 412 voter 
options. 


Turnout varies from 7.5 to more than 66 percent. Turnout is affected by community 
interest in particular issues or races; however, general trends occur based on the type of 
election. National elections draw far more voters than primaries or local elections. See the 
diagram at the end of this section for statistics on Primary and November elections. 


The Travis County Clerk conducts joint primaries for the Democratic and Republican 
Parties. Primary elections are held in March of even-numbered years with Primary runoffs 
occurring in May. At this time, only the Democratic and Republican Parties hold primary 


elections in Texas. Travis County runs joint primaries where both parties vote in the same 
location and share all voting system equipment. 


Texas voters do not register as members of a specific political party. They declare party 
affiliation when they arrive to vote in a primary election. Upon check-in at a polling location, 
a voter requests and votes a ballot for either the Democratic or Republican Party. The voter 
must vote in the same party if voting in the Primary runoff and may not crossover vote in the 
opposing party’s runoff election. 


Other political parties like the Green and Libertarian Parties conduct conventions to determine 
their candidates for the General Election. A person who does not claim a political party can 
file as an independent candidate on the General Election ballot. 


Straight party voting is allowed. Straight party voting is a ballot option in the November 
General election of even-numbered years. Voting “straight party” 1s not mandatory, and if the 
Straight Party race is selected, the voter may remove or change selections in any races on the 
General ballot. 


Some entities allow voters to select more than one candidate within a race. While most 
races are determined by voting for one candidate or choice, some entities have races where 
voters can select two or more candidates or choices (for example, “vote for one, two, or three 
of the following candidates”). 


The Clerk’s Elections Division usually conducts three to six elections per year. Odd- 
numbered years will likely consist of a May election with a possible June runoff and a 
November election. Even-numbered years likely consist of March Democratic and 
Republican primary elections with a possible May runoff, a May local election with a possible 
June runoff, and a November election with a possible December runoff. Other special 
elections and an odd-year December runoff election are also possible. 


Certain voters can vote by mail. Voters must qualify to vote by mail in Texas. 
Requirements for eligibility are that voters be: 


e 65 years of age or older; 

e Out of the county during the entire election period; 

e Sick or disabled; or 

e Confined in jail but eligible to vote. 

Uniformed service members, their families, and citizens residing outside of the United States 
are also eligible to vote using a Federal Post Card Application (FPCA). 


The volume of ballots voted by-mail in Travis County has been on the rise. The number of by- 
mail ballots in the 2014 Gubernatorial Primaries increased by more than 192% from the 2010 
Gubernatorial Primaries (from 2,011 to 5,877). If this trend toward voting by-mail continues, 
the volume in the 2016 Presidential election could grow from 18,844 ballots voted and 
returned in 2012 to more than 31,355. 


Texas law provides for the use of provisional and limited ballots. Both these instances 
require election workers to follow special procedures and for voting equipment to 
accommodate these unique situations. Provisional voting (Section 63.011 of the Texas 
Election Code) allows a voter whose name does not appear on the list of registered voters (due 
to possible administrative error) to vote. Provisional ballots are kept separate from the regular 


ballots until a review of the voter’s records can be performed. Limited ballots (Chapter 112 of 
the Texas Election Code) are only issued when a voter has moved to a new county and has not 
re-registered. A ballot must be created to provide the federal, statewide, and local district 
races that are similar between the voter’s new and old county. 


Early Voting is popular. Early Voting for each election typically runs 9 — 12 days, with 40% 
- 60% of ballots cast during this period, although this figure has been as high as 75%. The 
County runs 25 to 35 Early and Mobile Voting locations. Great effort is made to place these 
locations in areas of convenience and high foot traffic such as retail stores, mobile buildings 
and lobby areas. This sometimes creates logistical challenges with small or oddly shaped 
spaces, sparse electricity, and unreliable network connections. 

The County currently employs numerous security measures and plans to adapt and apply these 
to the new system. For example, law enforcement officials deliver the “electronic ballot 
boxes” to a secured area each night and return them to the polling locations the next morning. 


Travis County offers Election Day Vote Centers but must maintain the ability to conduct 
precinct voting. In November 2011, the County began using Vote Centers on Election Day. 
Vote Centers have proven to be highly appreciated by voters, but the County also must be 
prepared to provide traditional precinct voting elections. 


Unlike precinct voting where voters must vote only in their precinct, Vote Centers give any 
eligible Travis County voter the ability to vote at any polling location in Travis County on 
Election Day. Every polling location has every ballot style available for use. In a countywide 
election, approximately 190 to 210 polling locations are utilized. These polling locations 
typically have 3 to 20 voting stations. Large elections may sometimes necessitate the use of 
“Mega sites” that offer 20 to 50 voting stations. 


The infrastructure and technology that makes Vote Centers possible is the internet connection 
polling locations have to Travis County’s Voter Registration System through a Voter Check- 
In Station that is independent from the voting system. Therefore, Election Day operates 
similarly to Early Voting in that polling locations continuously give and receive live updates 
of information to the Voter Registration System. This allows voters the convenience of voting 
at any polling location and the security to prevent persons from casting a vote in more than 
one place on Election Day. 


On Election Night, judges are required to bring equipment and election materials to a 
Receiving Substation. Travis County currently uses four to five Receiving Substations. 
After the materials are checked in at the substations, law enforcement officials continuously 
deliver the electronic media with the tabulation information to the Central Counting Station. 
Currently, no electronic transmission of election result data occurs between the polling 
locations, Substations and the Central Counting Station. (However, STAR-Vote™ provides 
additional checks and balances by utilizing both electronic and physical delivery of this data. 
Data transmission is done on systems separate from the STAR-Vote™ voting and tabulations 
modules.) 


Many laws and mandates dictate the conduct of elections. There are many complex laws 
and requirements that pertain to voting. Most relating to this RFP can be found in federal 
laws; Texas law and Attorney General opinions; guidelines and advisories set forth by the 
Texas Secretary of State; local charters; and procedures written by the Travis County Clerk. 


Travis County Election Turnout Statistics 
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GENERAL INFORMATION 


2.1 Developing a New Business Structure 


Moving to a phased development and implementation impacts the STAR-Vote™ timeline but 
does not change the overall, long-term objectives. The near term objective and the subject of 
this RFP is development of the In-Person Voting/Tabulation module and implementing it in a 
live election. This accomplishment will drive the follow-on phases to complete the rest of the 
system. The long-term goals remain intact and include protecting the integrity of STAR- 
Vote™, reducing the need for Travis County to solely cover the cost of developing the 
complete system; providing a structure that encourages system and software openness, 
development of new ideas, and analyzed improvements; and offering STAR-Vote to other 
entities at a low cost. 


The completion of the contracts likely to be awarded as a result this RFP will facilitate 
development of a complete voting system that can arguably operate many years into the future. 
It is also a system that can be adopted and purchased by other counties. Travis County 
supports this adoption of STAR-Vote™ by other entities and believes the best way to move 
any opportunity forward is for interested counties to form a consortium with Travis County. 
To be able to extend the use of STAR-Vote™ to other counties, Travis County (or a 
consortium of other STAR-Vote™ counties) must retain all intellectual property and 
proprietary rights in and to the STAR-Vote™ Elements B, C (only the custom 
software/firmware for existing hardware) and all legally protectable elements and components 
of it. This ownership position excludes any rights in Element A, the EAC-Certified products, 
procured as part of this RFP. 


In this scenario: 


e Travis County (and/or a consortium) would own the copyright and all other IP rights 
(patents, trademarks, etc.) with the vendor disclaiming any of their prior patent (or 
other IP) coverage over STAR-Vote™; 


e Vendors would be contracted to provide services as independent contractors who will 
assign, transfer and set over to Travis County all right, title and interest in and to the 
STAR-Vote™ work product; 


e Source code for all modules would be published, but usage rights for actual elections as 
well as derivative rights (as in using the code to create a derivative voting system) 
would be controlled by Travis County (and/or consortium) with a view toward 
ultimately releasing usage and derivative rights under a “suitable” (as determined by 
Travis County and/or consortium) open source license that would allow and encourage 
preparation of third-party derivative work, recognizing that voting systems must be 
state and federally certified; 


e Source code for specific modules relating to third-party verification of the bulletin 
board and related published election artifacts would be published under a "suitable" (as 
determined by Travis County and/or consortium) open source license; and 


e During the period in which usage and derivative rights are retained by Travis County 
(and/or consortium), Travis County (and/or consortium) will commit to licensing all 
elements of STAR-Vote™ on a Reasonable and Non-Discriminatory (RAND) basis. 


e However, Travis County understands that this method of developing and implementing 
a voting system is new; therefore, the County is willing to discuss alternate business 
models that accomplish the same outcome during contract negotiations. 


2.2 Ownership of and Rights to Data Generated by STAR-Vote™ System 


Travis County will own all data generated or produced by the STAR-Vote™ system, or any 
element of it, when it is used by Travis County, regardless of the nature or form of the data and 
regardless of the medium in which the data are generated or produced. Upon their creation, the 
data will automatically become the sole and exclusive property of Travis County without 
limitation or restriction of any kind and regardless of whether the data are legally protectable 
as confidential or proprietary. 


2.3 Voter Registration Data 


In Travis County, the County Clerk’s Elections Division conducts elections and the Tax 
Assessor-Collector’s Voter Registration Office maintains the voter registration system and its 
data. The Tax Assessor-Collector’s Voter Registration Office uses a system called EZVote 
that was designed by and is supported by Hamer Enterprises of Texas. EZVote takes the GIS 
data of all county districts and compiles the district information into unique ballot 
combinations. There are instances in this RFP where information must be communicated 
between the Voter Registration System and STAR-Vote™ modules. The voter checkin 
module, which looks up voters in the registration system and prints out a code for the voter 
indicating the voter’s ballot style, is provided by Travis County however. 


2.4 Travis County’s Election Night Return System (ENR) 


The Travis County Clerk uses a real-time election reporting system that was designed by the 
Travis County Clerk’s Office and developed by Hamer Enterprises. It is referred to as the 
Election Night Reporting System or ENR. This public tool uses statistics, maps, and graphics 
to display voter turnout and cumulative and precinct-by-precinct election results. ENR 
provides these results throughout Election Night, reports updates and the final canvass, and 
archives past election results for interactive viewing. This tool allows the public to create and 
produce customizable, downloadable reports in a variety of formats. 


At this time, the Clerk’s Office manages ENR within its own cloud at an off-site hosting 
company using a site-to-site VPN tunnel. This solution is subject to change and any proposed 
system must be able to operate within premise on-site hosting or off-site with a hosting 
provider. Respondents to this RFP may submit alternative recommendations for consideration. 


The system developed by this RFP must be able to provide the County’s ENR with near real- 
time, continuously-updated election data and final official results in a means and format that 
operates rapidly and seamlessly for the public’s use. 


The Travis County ENR site is at www.traviselectionresults.com. 


2.5 Phased Implementation 


The STAR-Vote™ system requirements were developed from the ground up with the purpose, 
among other objectives, of specifying an entire voting system developed under the open source 
code software model. Building and implementing the complete STAR-Vote™ system requires 
a wide range of skills that were unlikely to be resident within a single company. Furthermore, 
the practical reality of budget, time and functionality required us to evaluate the best approach 
that yields the highest likelihood of success. The County determined that a phased approach 


toward complete development and implementation, where the first phase builds the in-person 
voting module of the STAR-Vote™ system, is the optimum strategy. This RFP is requesting 
responses for first phase of development and implementation of STAR-Vote'M, 


The architecture has been organized to focus on the implementation of the in-person voting 
polling place system to support Election Day and Early Voting elections. The polling place 
system, or In-Person Voting/Tabulation module, embodies the STAR-Vote™ design for open 
source code, running on COTS hardware, and provides a robust security architecture that 
supports Risk Limiting Audits (RLAs). An objective of this RFP is to contract for the 
development of the In-Person Voting/Tabulation module and the corresponding Support 
Modules as defined by the STAR-Vote™ specification and requirements. The other open 
source code components will be developed in a follow on phase. The first phase of the STAR- 
Vote™ Precinct Voting and Tabulation module will be supported by existing, commercially 
available, EAC-Certified products, which this RFP is also seeking. 


Travis County desires to contract with a company that has existing ballot definition/election 
management, by-mail and tabulation products that are EAC-Certified. This architectural 
approach minimizes the election expertise necessary to develop the Precinct Voting and 
Tabulation module and takes advantage of mature election products. The intent is to 
implement the certified products “as-is” to maintain the certified status. If any requirement 
contained in this RFP conflicts or does not align with existing, certified functionality, the 
County urges Proposers to note the exception in their response as a deviation (see Part I, 
Section D, paragraph 2.0) for evaluation by the County. The County intentionally did not 
provide exhaustive requirements for these products but is relying on the VVSG and the market 
to validate the functionality. The interface between the Precinct Voting and Tabulation 
module and the EAC-certified products is straightforward and utilizes a practice that most 
election products already support: export of an election definition file, and import and 
aggregation of election results. Greater details of this interface will be defined during contract 
negotiations with the contract award finalists. 


This RFP allows for multiple awards to different vendors and companies and it is very likely 
that awards will be given to two or more different enterprises. Multiple awards requires Travis 
County to provide a system integration function to manage and coordinate the interactions 
between awardees for the length of the contract. The County is prepared to provide this level 
of support to the awardee’s project managers for the project. Further, given the fact that the 
cryptographic solution for STAR-Vote™ is already designed, 


Travis County will provide design support expertise for the software development effort for 
this functionality. The County anticipates this RFP will result in awards for the STAR-Vote™ 
In-Person Voting/Tabulation and Support Modules, Ballot Box Scanner software and/or 
hardware development, EAC-Certified products; and possible awards for the Red Team 
Assurance requirements and Human Factors evaluation as outlined in the body of the RFP. 


2.6 Red Team Assurance 


Development, testing and implementation of the STAR-Vote™ In-Person Voting/Tabulation 
and Support modules includes the use of a “Red Team”. The Red Team is a group of software 
and security experts who: (i) provide independent review of the functional and security 
elements of the STAR-Vote™ system and test the effectiveness of the security and controls; 
(ii) identify vulnerabilities; and (iii) recommend changes to reduce risks. The Red Team 
Assurance requirements of this RFP are offered as a separate component that is open for 
proposals by qualified vendors other than respondents of the In-Person Voting/Tabulation 
module. Vendors responding to the In-Person Voting/Tabulation portion of this proposal must 


agree to the use of a Red Team. The vendors will coordinate tasks and schedules as part of the 
contract discussions for RFP awards. Any disputes between the Red Team and the In-Person 
Voting/Tabulation vendor over the course of the project will be adjudicated by Travis County. 


Qualified entities or organization are encouraged to submit a proposal for the Red Team 
Assurance function based on the product requirements outlined in this RFP. Proposals should 
address both the development stage of the In-Person Voting/Tabulation and Support modules 
and run-time testing. These tasks may include: 


e Requirements Review: Review and input for system requirements to identify additional 
security requirements prior to any code development. 


e Design: Review software design and component architecture to identify security issues 
and recommend mitigations. 


e Coding and Implementation: Be cognizant of components and code blocks used by 
developers and advise on potential inherent vulnerabilities; provide guidance on secure 
coding practices and other mitigation strategies. 


e Verification: Design, develop and execute a set of runtime tests that includes specific 
security tests and likely includes penetration testing. 


These types of Red Team tasks generally reside within the “application security” field and 
relate to the In-Person Voting/Tabulation software that will be developed as part of this RFP. 
The In-Person Voting/Tabulation module has three principal “software applications”, which 
are compiled code blocks that perform the Voting Station, Ballot Controller Station and Ballot 
Box/Scanner functions. For the purposes of submitting a Red Team Assurance proposal, 
Proposers should assume the COTS hardware platform for the software application is a generic 
tablet computer. Adjustment in project tasks for variation in the hardware platform will be 
made during contract negotiations. 


There are other system elements, components and modules that are a part of the STAR-Vote™ 
implementation outside of the software applications referenced above that present potential 
security risks and require review and testing. While the STAR-Vote™ system does not 
include any public-facing websites or web applications, the various components and modules 
operate on a networked architecture. Proposals for the Red Team Assurance function should 
address the networked aspects of the interconnected modules and propose a security review 
and testing program that encompasses the In-Person Voting/Tabulation module, Support 
Modules and the interface with the EAC-Certified Modules. The types of tasks that may be 
included in this review and testing are: 


e Overall Software Security Strategy 
e Architecture Analysis 
Dynamic Application Security Testing (DAST) 
Static Analysis Security Testing (SAST) 
e System Assessment, which may include; 
o Documentation review 
o Log file review 
o Ruleset and system configuration review 
o Network sniffing 
o File integrity checking 
e Target Identification and Analysis 


Testing using automated tools 
Identify systems, ports, services, and potential vulnerabilities 
Network discovery 
Vulnerability scanning 
o Wireless scanning 
e Vulnerability Validation 
o Password cracking 
o Penetration testing 
o Social engineering 
o Application security testing 
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Travis County is seeking Red Team Assurance proposals that are tailored for STAR-Vote™. 
Proposals should be modularly priced so the Red Team Assurance effort can be further refined 
to align with the development of the In-Person Voting/Tabulation module and the overall 
project budget. 


2.7 Human Factors Evaluation 


A principal goal of STAR-Vote™ is to be highly accessible and intuitively usable by all voters. 
This RFP embodies state-of-the-art accessibility and usability requirements but citing these 
references does not ensure STAR-Vote™ will exemplify these performance qualities. In an 
effort to highlight the importance of accessibility and usability, Travis County intends to 
procure services from qualified providers to provide human factors evaluations, oversight, 
testing and general User Centered Design guidance for development of the In-Person 
Voting/Tabulation module defined in this RFP. 


The County recommends that human factors evaluation proposals address the following types 
of topics: 


User interfaces for the voter that are intuitive, straightforward and logical; 
Assessment of suitable COTS equipment for user familiarity; 

Flow of voters through the polling locations; 

Ballot design follows Anywhere Ballot and AIGA Design for Democracy; 
Design process employs UCD-based iterative design methodologies, and; 
Content and delivery of any instructions for voters and poll workers. 


The County envisions this human factors evaluation effort as primarily the application of 
existing information and research that has been performed for accessibility and usability of 
voting systems. Further, the County recommends that proposals follow the NIST Voting 
Performance Protocol (VPP), which can be found at: 


http://www.nist.gov/itl/vote/upload/Usability-Benchmarks-080907.doc 


The County further recommends that the results be reported in the NIST Voting Common 
Industry Format (NIST VCIF) found at: 


http://www.nist.gov/itl/vote/upload/Guidelines_CIF_Template_Laboratories.pdf 


This protocol should be followed with two exceptions: 


1) The County recommends that the test ballot and the directed voting lists given in 
Attachment 9 of this RFP be used instead of the test ballot contained in Appendix A of 
the NIST references. The reason for this substitution is that there is a large body of 


benchmark data for systems that have used this ballot, so reliable comparisons can be 
made. 


2) The County recommends that the System Usability Scale [see Bangor, A., Kortum, P. 
T., & Miller, J. T. (2008). “An empirical evaluation of the system usability scale.” Intl. 
Journal of Human—Computer Interaction, 24(6), 574-594.] be used at the end of the test 
to measure satisfaction (in addition to the measure recommended by NIST). The reason 
for this addition is that there is a large body of benchmark literature for voting systems 
and other commercial products that is highly informative as to the usability of the system. 


The County recognizes that STAR-Vote™ may have some unique features not previously 
addressed by the existing body of knowledge and that some research may be required; 
however, the County believes this would be a limited effort that will help minimize costs. 
Human factors evaluation proposers should expect to work side-by-side with other vendors and 
Travis County staff to apply usability and accessibility concepts and practices. Travis County 
will serve as the systems integrator and will moderate the relationships between vendors. 


Human factors evaluation proposals should outline project tasks based on the design and 
development requirements for the In-Person Voting/Tabulation module. Task durations in the 
form of a Gantt chart or some other suitable representation of the level of effort required 
should be provided along with general task sequence or relationship. The final schedule will 
be determined during contract negotiation by working with Travis County and the other 
STAR-Vote™ vendor(s). Human factors evaluation proposers are expected to provide project 
management skills to manage their interface with the rest of the project. 


2.8 Use of Current and Commercially Available Hardware and Software 


Proposals must incorporate a plan for the predominant use of commercial off-the-shelf 
hardware and associated software and include a proposed hardware platform to satisfy the 
requirements of this RFP. Commercial off-the-shelf (COTS) hardware and software are 
products that do not require custom development before installation and that are generally 
available and user-friendly. 


The proposed hardware must be current-generation off-the-shelf hardware that maximizes 
security, ease of use, function, flexibility, reliability, and portability. Pricing, availability and 
supplier(s) must also be included for the proposed hardware. 


The proposal must also assume and plan for ways to adopt and adapt to continuously 
improving technology. Since future COTS platforms will have new hardware and software 
features that cannot be completely anticipated, the Proposer may want to propose, as part of an 
ongoing maintenance contract, fees and services for porting and otherwise updating STAR- 
Vote™ to operate with new COTS devices as they arise. 


Other than Element C, Ballot Box/Scanner, if proposed hardware is not COTS, a specific 
justification must be provided that explains why a non-COTS solution is required, a 
breakdown of the components of the recommended hardware with notations by the parts within 
it that are COTS, and an outline as to how the price for this customized hardware was derived 
and a plan for product development, testing and manufacturing. Additional information 
regarding warranties, replacement, and cost may be requested if a solution requires COTS 
equipment to be located inside of or attached to a non-COTS structure. 


The proposed solutions must provide explanatory information if any equipment and/or related 
furniture, components, etc. do not meet VVSG or accessibility requirements. 


2.9 Recommendation for Use of Thermal Printers 


Travis County’s research indicates that thermal printers in the polling location provide the best 
solution, and their use is described throughout this RFP. Thermal printers: 


Are small and lightweight; 

Print at an acceptable rate of speed; 

Do not rely on ink cartridges or toner; 

Produce clear, readable, crisp, dark text; 

Are able to run for long periods of time on battery power; 

Are less expensive to purchase, maintain, and operate; and 

Can last longer with frequent handling than other types of printers. 


Our information shows that relatively new types of high-quality thermal paper can withstand 
reasonably high levels of heat and UV rays and maintain its quality for at least two years (the 
required retention period). 


Vendors should consider the potential weather conditions in Texas when proposing hardware 
and consumables. 


Sheet fed thermal paper is preferred to continuous feed paper due to usability considerations, 
such as reloading, user tear-off errors, misfeeds, and alignment issues. 


Alternatives to thermal printers will be considered if the proposal demonstrates that 
requirements can be met and costs are reasonable. 


2.10 Accessibility Is a Priority 


Giving all voters the right to vote using the same voting device is an important principle that 
drives the design of the STAR-Vote™ system. Creativity and ideas based on the latest 
technology and philosophies are encouraged. 


There are many outstanding resources on this topic, for example: 


e Georgia Tech Research Institute: The Information Technology and Innovation 
Foundation Accessible Voting Technology Initiative Working Paper Series #7 


(http://elections.itif.org/wp-content/uploads/A VTI-017-GTRI-VSAPEval-2013.pdf ) 
e Numerous papers provided by the Caltech/MIT Voting Technology Project 
(http://vote.caltech.edu/wparchive ) 


e Work being done by the Los Angeles County Clerk 
(http://apps1.lavote.net/voter/VSAP/ >) 
e Jill Piner’s dissertation on design of an accessible audio voting system 


e  (http://chil.rice.edu/gpiner/PinerDissertation.pdf) 
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Voluntary Voting System Guidelines Compliance 


2.11.1 In-Person Voting/Tabulation module 
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Any proposed solution to fulfill the In-Person Voting/Tabulation module specified in 
this RFP must be developed to fully comply with all elements of the 2012 Draft 
VVSG pertaining to voter interaction and accessibility, except for those items listed 
in Attachment 2 as incompatible with STAR-Vote™. In addition, the successful 
proposal must comply with all aspects of the 2005 VVSG 1.0, except in such places 
as discussed in Attachment 2 as not being compatible with STAR-Vote™. The 
Proposer must agree to work with Travis County in an effort to resolve any 
incompatibles. 


Unless otherwise specified herein, all references to the Voluntary Voting System 
Guidelines (VVSG) refer to the VVSG 1.1, the 2012 draft revision. At the time of 
this RFP’s writing, a copy of the 2012 VVSG revision can be found at: 


http://www.eac.gov/assets/1/Documents/V VSG%20Version%201.1%20Volume%20 
1%20Public%20Comment%20Version-8.31.2012.pdf 


This should be the VVSG Version 1.1 Draft dated 8/31/2012. If the document is not 
available or does not match that version or date, please contact 
Lori.Clyde @traviscountytx.gov for a copy of the correct document. 


Should a newer version of the VVSG become available, the vendor must continue to 
function within the guidelines of the 2012 draft referenced above unless instructions 
are issued from Travis County to the contrary. If the Proposer believes that some 
aspect of this document is in conflict with VVSG recommendations, this document 
takes precedence, but the Proposer must notify Travis County of the conflict so that 
it may be considered and the RFP can be amended if necessary. 


EAC-Certified Modules 


Any products proposed to satisfy the RFP requirements for the EAC-Certified 
modules must include a copy of the Certificate of Conformance issued by the EAC 
that identifies the product name, version number and the version of the VVSG that 
the product was certified against. If proposed products are not currently certified by 
the EAC at the time the RFP responses are due, the Proposer must submit the 
proposed products and provide proof of EAC certification submission at contract 
negotiations. Any new certification requires compliance with the VVSG as well as 
any advisories and requirements set forth by the EAC. 


2.12 Texas Election Law and Secretary of State Voting System Guidelines 
2.12.1 In-Person Voting/Tabulation module 


2.12.2 


Any system proposed as a solution to fulfill the In-Person Voting/Tabulation module 
specified in this RFP must be developed to fully comply with all elements of Texas 
law as well as any advisories and requirements set forth by the Texas Secretary of 
State, except for those items listed in the Gap Analysis in Attachment 3 as 
incompatible with STAR-Vote™. The Proposer shall agree to work with Travis 
County in an effort to resolve any incompatibles. 


EAC-Certified Modules 
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Any products proposed to satisfy the RFP requirements for the EAC-Certified 
modules must either be certified by the Texas Secretary of State or, if not certified, 
include a plan and timeline that outlines the process to attain Texas certification 
prior to the completion of the contract. Any new certification requires compliance 
with Texas law as well as any advisories and requirements set forth by the Texas 
Secretary of State, except for those items listed in the Gap Analysis in the 
Attachment 3 as incompatible with STAR-Vote™. The Proposer shall agree to work 
with Travis County in an effort to resolve any incompatibles. Proposers are 
contractually required to submit and attain certification by the Texas Secretary of 
State, and failure to achieve this requirement will result in contract termination. 


An Overview of the STAR-Vote™ System 


The following is a brief description of how the County imagines STAR-Vote™ functioning in 
practical application. The County’s goal is to give Proposers an understanding of Travis County’s 
current elections processes and provide a narrative of the County’s overall vision of a new 
system. The narrative outlines the functional implementation of this phaseof the system and the 
County urges Proposers to review the STAR-Vote™ Voting System paper referenced elsewhere 
in the RFP for the long-term implementation of the complete system. 


3.1 Before the Election 


The election cycle begins with the Administrator entering data into the STAR-Vote™ 
Election Definition and Ballot Generation module. The Administrator has access to a site for 
confirmation of the voter registration system’s district/precinct information and utilizes data 
entry screens to input ballot text and record audio information in the EAC-Certified product. 
The module uses this information to build the ballots and produces approximations of how 
the ballot will look and sound. 


This Election Definition and Ballot Generation module uses district/precinct information 
from the voter registration database and the ballot information derived from the active 
contests and races to create ballot styles. After everything has been carefully proofed, 
reviewed, and formally accepted, the Administrator generates the Election Definition File 
and exports it to a secure, non-volatile data distribution medium. 


The Administrator loads the Election Definition file into the EAC-Certified component for 
By-Mail Ballot Generation and the STAR-Vote™ In-Person Voting/Tabulation module where 
the file is used build and format ballots for use in the election. The In-Person Ballot 
Assembly and Generation module provides formatting templates to arrange the ballot data for 
display on the target Voting Station hardware. The templates also enforce formatting rules 
so the ballots comply with usability and accessibility requirements. This process also 
integrates the audio data supplied with the Election Definition file and allows the text and 
audio to be proofed synchronously. 


After the ballots are proofed and generated for Precinct Voting, the Precinct Voting Election 
Definition file is loaded onto a subset of computers, Ballot Control Stations, and Voting 
Stations to be used in testing. On a separate computer, the Test Data Generator prepares sets 
of trial data for extensively testing the hardware, software, and ballot programming. When 
testing is complete with 100% accuracy, the Administrator’s staff downloads the Precinct 
Voting Election Definition file to the remaining equipment and prepares it for deployment. 


Before Early Voting, Voting Stations are delivered to and secured at the polling places. 
Election Judges pick up the Ballot Control Stations and other election materials before voting 
begins. At the end of each day of the Early Voting period, a team of law enforcement 
officials picks up the Ballot Control Stations and transports them back to a secured area in 
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the Administrator’s office. In the morning, these officers return and transport the Ballot 
Control Stations back out to the Early Voting locations. 


Prior to Election Day, the Voting Stations are delivered to and secured at the polling 
locations. Election Judges pick up the Ballot Control Stations and election materials a day or 
more before Election Day. On Election Day, Judges arrive at the polls with the Ballot 
Control Stations, connect and test all devices, complete setup of the locations, and begin 
processing voters at 7:00 a.m. 


In-Person Early Voting and Election Day Polling Locations 


Each polling location has at least one Voter Check-In Station, at least one Ballot Controller 
Station (BCS), at least one Voting Station, Audio Ballot Reader(s), and at least one Ballot 
Box/Scanner. The BCS, Voting Stations, and the Ballot Box/Scanner are networked together 
via a standard Ethernet wired network so that they can communicate with one another. The 
number of devices in a polling location is dependent upon the estimated number of voters, 
the space limitations of the facility, and the number of Voting Stations that can be safely and 
efficiently managed by poll workers when networked to a BCS. (Please note that Early 
Voting equipment is rarely reused on Election Day.) 


Voter Check-In Station: This system resides outside of the STAR-Vote™ architecture and 
is connected to the jurisdiction’s voter registration system, which is used to qualify and check 
in each voter. When the voter leaves the Voter Check-In Station, he or she receives a slip of 
paper called the Ballot Style Token that contains a barcode of the voter’s ballot style. The 
Voter Check-in Station is provided by the County and not part of this RFP. 


Ballot Control Station (BCS): The BCS is the control center for the polling place. When a 
voter presents a Ballot Style Token at the BCS, it scans the Token’s ballot style barcode and 
generates a 5-digit passcode called a Voting Ticket. This station also manages provisional 
and spoiled/challenged ballots, monitors connections and activities of the Voting Stations, 
stores encrypted copies of all voter selections, and validates voters’ records as they are 
placed into the Ballot Box/Scanner. 


Voting Stations: Voters make ballot selections on Voting Stations either by using a touch- 
screen or an accessibility-enabling device. After the voter reviews a summary screen and 
confirms ballot choices, the system creates an encrypted Electronic Vote Record (EVR). The 
Voting Station then prints two documents. The first is a printed record of the voter’s choices 
with a barcode identifier. This is called the Printed Vote Record (PVR). The second is a 
printed Receipt that the voter keeps for reference, and which is printed in such order that, 
when picked up by the voter, it will be on top of the PVR for privacy. In addition to the 
information resident on each Voting Station, every Voting Station stores the data from all 
other Voting Stations, BCSs, and Ballot Box/Scanners connected to it. 


Ballot Box/Scanner: A Ballot Box/Scanner is a barcode scanner with a paper feeder affixed 
to a ballot box. The voter takes his or her printed summary of choices (the PVR) and feeds it 
through the scanner. This scanner reads only the barcode identifier on the PVR. It does not 
read the content of the voter’s choices. Once the Ballot Box/Scanner successfully reads the 
PVR barcode, it relays a message to the BCS to consider the related EVR as cast. The BCS 
returns a message to the Ballot Box/Scanner indicating either to accept or reject the PVR. If 
accepted, the paper feeder advances, deposits the PVR into the secure ballot box and adds 
identifying information to the electronic manifest for the contents of the ballot box. If 
rejected, the BCS indicates the reason for the rejection and notifies the Ballot Box/Scanner to 
eject the PVR. 
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Audio Ballot Readers: This is not to be confused with the headset that may be used directly 
on a Voting Station to read instructions and ballot choices to a voter. Instead, this allows a 
voter with visual challenges a separate and independent method of reviewing PVR content 
before feeding the PVR into the Ballot Box/Scanner. Audio Ballot Readers are independent 
stations that are not connected to the Voting Stations, but can be part of a Voting Station 
setup. An Audio Ballot Reader scans the PVR text and utilizes a headset to audibly read the 
PVR content to the voter. This is an optional step for the voter, but it gives a person with a 
visual impairment the same opportunity any sighted voter would have to verify the 
electronically printed ballot choices before the vote is cast. 


How a Voter Moves Through the Polling Place 


From the voter’s point of view, the process can be accomplished in four steps: 


Step 1 Step 2 Step 3 Step 4 
Voter is qualified at Voter has Token scanned Voter enters the passcode Voter verifies the printed 
the Voter Check-In by a poll worker at the at the Voting Station and choices, feeds the PVR 
Station and receives Ballot Control Station and makes ballot selections. into the Ballot 
a Ballot Style Token. receives a 5-digit Voter prints a paper Box/Scanner, and leaves 
passcode called the record of the choices the polling place with the 
Voting Ticket. (PVR) and a receipt. receipt. 
-- 
Check-In | Box/Scanner 


Ballot Cast 


Station 
(BCS) 


Voting 


Ticket 
S-digit 


Printed Receipt 
Vote hash code 


Ballot Style 
Token 


passcode Record 


(PVR) 


Here is a more detailed explanation of the dynamics at work: 


Step 1: The voter checks in with a poll worker. The poll worker uses the Voter Check-In 
Station (not a part of this RFP) to confirm the voter is properly registered and determine the 
voter’s precinct. The Voter Check-In Station then generates a piece of paper called the 
Ballot Style Token that contains an alpha-numeric and 1-D barcode representation of the 
appropriate ballot style. See Attachment 4 for current samples of Ballot Style Tokens. 


If the voter’s registration cannot be verified, the voter provides the poll worker with required 
information, and the poll worker gives the voter a Ballot Style Token that indicates both the 
proper ballot style and the provisional status of the ballot (Texas Election Code 63.011). 
Nothing on this token is secret, nor is the ballot style unique to any individual voter. 


Step 2: The voter takes the Ballot Style Token to a poll worker at a BCS. The poll worker 
scans the barcode and the BCS prints a Voting Ticket, a piece of paper printed with a 5-digit 
passcode. The Ticket also indicates if the voter is voting a provisional ballot. 


Step 3: The voter selects any available Voting Station and scans or enters the code from the 
Voting Ticket into the Voting Station. The Voting Ticket Code identifies the assigned 
precinct/ballot style including the designation of a provisional ballot. Once the voter enters 
the code, it is transmitted over the local network to the BCS. The BCS immediately 


invalidates the use of that code on the other devices. The code’s status (issued, in use, voted, 
expired, cancelled, etc.) can be checked at the BCS at any time during the voting period. 
Each BCS generates access codes randomly subject to the constraint that no code is repeated 
within a polling location during a voting period, which requires coordination among BCSs if 
multiple units are operating in the same polling locations. Codes are not permanently linked 
to the voting record or the voter, as that could compromise voter anonymity. 


The voter makes selections on the touchscreen or with the aid of an accessibility-enabling 
device. When the voter completes making ballot selections, the Voting Station displays a 
review screen (and/or its auditory equivalent) for the voter to confirm all selections before 
printing a paper record. 


When the voter finishes making selections, the Voting Station encrypts and stores this 
information as an Electronic Vote Record (EVR), and prints two documents using a printer: 


e A Printed Vote Record (PVR): This is a single or multi-page printed vote record that 
includes a human-readable summary of the voter’s selections and a barcode encoding 
four types of numbers - a random (non-sequential) page identifier (PID) unique to each 
page, a (possibly sequential) page casting identifier (PCID) used only inside the polling 
location and unique to each page, the precinct/ballot style, and the page number. These 
numbers are printed under the barcode in plain text. See Attachment 5 for an example 
of a PVR. 


e A paper take-home receipt: This receipt identifies the Voting Station used and the date 
and time of the vote, and contains a short (16-20 character) hash code that serves as a 
commitment to the vote but does not reveal its contents. See Attachment 6 for an 
example of a Receipt. 


The voter reviews the PVR to confirm the ballot selections. Voters who cannot read the paper 
may use an Audio Ballot Reader. The Audio Ballot Reader is configured with the audio file 
from the Election Definition File for the election and is able to scan the paper and read the 
contents back to the voter via headphones. The Reader is an independent standalone device 
that does not communicate with the Voting Station. 


Step 4: If the voter is ready to cast the ballot, he or she takes the printed vote record (PVR) 
to the Ballot Box/Scanner. The Ballot Box/Scanner has a paper feeder and simple barcode 
scanner that reads the page casting identifier (PCID) from the composite barcode on each 
page of the PVR and communicates this to the BCS. This allows for the validation of the 
electronic vote (EVR). The BCS confirms that the PCID corresponds to a valid PVR page 
(produced by a properly registered voter, not provisional) and transmits a hash of the 
Electronic Vote Record that is associated with the PCID to all devices on the network. 


This process creates a record of which ballots are cast (deposited in the Ballot Box/Scanner), 
and therefore, which ballots should be tabulated. An Electronic Vote Record is not 
considered cast and is not included in the tally unless, and until, its corresponding PVR has 
been deposited in the Ballot Box/Scanner. If the voter places only some pages of a multiple- 
page PVR into a Ballot Box Scanner, the final tally includes only the votes on those pages. 
The Ballot Box/Scanner ejects PVRs with invalid PCIDs, PVRs corresponding to provisional 
ballots, and PVRs that are expired. When the EVR is accepted, the PCID(s), PID and ballot 
precinct name/number for the cast ballot is added to a Ballot Manifest managed by the Ballot 
Box/Scanner. 


The voter exits the polling location with the paper receipt containing the hash code for the 
ballot placed in the Ballot Box/Scanner, in a human readable format, divided into blocks of 


3-4 characters to facilitate manual data entry. After results are published on election night, 
the voter may go to the County offices to access the Bulletin Board, enter his or her hash 
code and verify the status of the ballot(s). The receipts should also contain a QR code with a 
direct link to the bulletin board with the hash pre-filled. 


Data flow for the polling location process is as follows: 


Step 1 Step2 Step 3 

Voter is qualified Poll worker uses a scanner to scan the ballot style barcode Voter enters the five-digit passcode onto a Voting Station 
at the Voter into the BCS. A small thermal printer attached to the BCS screen which opens the proper ballot style and tells the 
Check-In Station prints a S-digit passcode which is handed to voter. The BCS BCS that the station is in use. Voter makes ballot selections 
and receives a communicates the passcode and ballot style data to all and prints a paper record (PVR) of the selections along 
Ballot Style Token. networked Voting Stations. with a receipt containing a hash code of the selections. The 


encrypted ballot data, audit logs, and message logs are 
broadcast and saved to the BCS and all networked Voting 
Stations. 


Voting Ticket 
S-digit 
passcode 


Voter Thermal Printer 
Check-In 


Ballot Style 
Witt 
e 


Barcode Scanner. 
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Step 4 
Voter feeds the PVR into the Ballot Box/Scanner. The 
Ballot Box/Scanner reads the barcode on the PVR and 
tells the BCS to mark the encrypted electronic ballot as 
CAST. A PVR is not cast until it is placed into the Ballot 
Box/Scanner. The voter retains the receipt to verify the 


Printed hash code on a Public Bulletin Board, if desired. Public 


Vote Bulletin Board information is published on the web on 
Record Receipt election night when results are reported. 
hash code DA A 
(PVR) Voter Exits 
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3.4 Polling Place Flow for Voter Using the Audio PVR Reader 


The polling location includes an option for voters who wish to use an audio reader to review 
their Printed Vote Records (PVRs). The following diagram illustrates how this additional 
step occurs. 


Step 1 Step 2 Step 3 Step 4 Step 5 
Voter is qualified Voter has Token scanned Voter enters the Voter verifies the printed Voter feeds the PVRinto 
at the Voter by a poll worker at the passcode at the Voting choices using the Ballot Box/Scanner 
Check-in Station Ballot Control Station and Station and makes headphones and an and leaves the polling 
and receives a receives a 5-digit ballot selections. Voter independent audio place with the receipt. 
Ballot Style Token. passcode called the prints a paper record of reader. 

Voting Ticket. the choices (PVR) and a 


receipt. a" 
T 4 


Voter Independent Ballot 
-» -> 
Check-In Ballot Reader Box/Scanner 


Ballot Cast 


Ballot Style e 
Printer 


Printed Receipt 
Vote hash code 


Voting 
Ticket 


5-digit 
passcode 


Record 
(PVR) 
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Spoiled Ballots or Ballots that Are Challenged for the Parallel Testing Process 


If a voter wishes to change his or her ballot selections after the PVR has been printed and 
before it is placed in the Ballot Box/Scanner, a voter may “spoil” a PVR and vote a new 
ballot (Texas Election Code 64.007). In STAR-Vote™, a voter may use this process to 
“challenge” a ballot using the same procedures in order to test whether the voting station is 
recording votes correctly (a new process not currently addressed in law). 


To spoil or challenge a ballot, the voter, before going to the Ballot Box/Scanner, takes the 
PVR and the receipt to a poll worker at the BCS and asks to spoil or challenge the ballot. 
The poll worker indicates on the face of the PVR and the receipt that they are 
spoiled/challenged. The poll worker scans the PCID of the PVR into the BCS, and the BCS 
records that the PVR is spoiled/challenged. A message appears on the BCS asking the poll 
worker if the voter is requesting a new ballot. If the voter wants a new ballot, the poll worker 
prints a new Voting Ticket with a new 5-digit passcode, and the voter returns to a Voting 
Station to vote a new ballot. 


Any Electronic Vote Record (EVR) page whose paper record (PVR) is not read by the Ballot 
Box/Scanner is designated as spoiled or challenged. In Texas, the voter can spoil up to three 
ballots. Once the voter places the PVR into the Ballot Box/Scanner, the voter cannot make 
any changes. 


If a voter spoils or challenges a ballot, that ballot is used in a post-election audit. Depending 
on the specific procedures of the audit, every spoiled or challenged ballot, or a sample 
number of these ballots, is checked against the corresponding Electronic Vote Record to 
confirm the accuracy of the system. This process creates a means for performing a live, 
parallel test of the Voting Stations in the field. 


Depending on varying state laws and guidelines, the Bulletin Board can display the decrypted 
content of these ballots. At this time, Travis County is not planning to offer the decrypted 
content of the spoiled/challenged ballots on the Bulletin Board. 


The workflow for a spoiled/challenged ballot at the polling location is as follows: 


Step 1 


Voter makes ballot 
selections and prints a PVR 
and receipt. Voter asks a 
poll worker to 
spoil/challenge the ballot. 
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Step 2 

Instead of feeding the 
PVR into the ballot 
box/scanner to cast the 
ballot, the voter hands 
the PVR and receipt to 
the poll worker. 


Step 3 

Poll worker stamps SPOILED on 
both items and scans the PVR 
barcode into the BCS to identify 
the PVRas spoiled. The poll 
worker retains the spoiled PVR 
and hands the receipt back to 
the voter. The PVR is reviewed 
during the post-election audit. 


Step 4 

When the BCS is notified of a 
spoiled ballot, it asks the poll 
worker if a new ballot is to be 
issued. If so, the poll worker 
prints a new passcode and the 
voter returns to a Voting 
Station to continue the voting 
process. A ballot is not 


considered cast until the voter 
feeds a PVR into the Ballot 
Box/Scanner. 


Ballot 
Box/Scanner 


Receipt 
hash code 


AS 


Printed 
Vote 
Record 


Provisional Ballots 


If 1t is a determined that a voter must cast a provisional ballot (Section 63.011 of the Texas 
Election Code), the poll worker at the Voter Check-In Station assists the voter to complete 
the provisional ballot form/envelope. The voter then receives a Ballot Style Token that 
provides the ballot style and an indication that it is for a provisional vote. See Attachment 4 
for an example of a provisional Ballot Style Token. 


When the Token is scanned at the BCS, the BCS issues a 5-digit passcode that alerts the 
system of the ballot’s provisional status. At the Voting Station, the voter enters this passcode 
and makes ballot selections. The system creates an Electronic Vote Record (EVR) of the 
voter’s choices and marks it as “provisional pending.” The Voting Station prints out the 
PVR and the voter’s receipt. The identifiers on these documents designate this vote as 
provisional. 


The voter returns to the poll worker table and seals the PVR into a privacy envelope. The 
poll worker seals the privacy envelope into the provisional ballot form/envelope and secures 
it in a ballot box specifically for provisional PVRs. If a voter attempts to place a provisional 
PVR in the Ballot Box/Scanner, it is ejected. The voter retains the provisional ballot receipt 
and can use it to see if the ballot is eventually accepted and counted. 


After Election Day, the Voter Registrar reviews all of the provisional voters’ registration 
information and sends the findings to the Early Voting Ballot Board (EVBB) for final 
consideration. The EVBB opens the accepted provisional ballot form/envelopes and places 
the PVRs, contained in privacy envelopes, into a ballot box. 


The EVBB then opens the ballot box and removes the provisional PVRs from the privacy 
envelopes. They feed these PVRs into a Ballot Box/Scanner, the system records them as 
“accepted provisionals,” and includes the votes in the tally. 


The workflow for a provisional ballot within the polling place is as follows: 


Step 1 Step 2 Step 3 Step 4 
Voter is qualified at the Poll worker scans the Voter enters the five-digit Ballot Box/Scanner does not accept 
Voter Check-In Station and Token at the Ballot passcode at the Voting Station Provisional PVRs. The voter must take the 
receives a Ballot Style Token Control Station. Voter which opens the provisional PVRto the polling location judge, place the 
with an indication it is for a receives the Voting ballot. Voter makes ballot PVR into the provisional envelope, and place 
provisional ballot. Voter, Ticket containing a 5- selections and prints a paper the envelope nto the provisional ballot box. 
with poll worker assistance, digit passcode. record (PVR), encoded as The voter retains the receipt to check the 
prepares provisional provisional, and a receipt. status of the provisional ballot (accepted or 
paperwork and envelope. rejected), and, if accepted, to verify the hash 
code on a Public Bulletin Board. 
Voter Ballot 
---- ----- - - 
Check-in es Box/Scanner 
Provisional 
Ballot Style Printer 
Ballot Cast 
Printed Provisional | __ Provisional 
Vote Envelope Ballot Box 
Record 
Receipt [------------- co 
(PVR) hash ae Voter exits 
3.7 Emergency Paper Ballots 
In the case of an emergency, such as a power outage or an incident that causes the evacuation 
of a polling location, Election Judges are instructed to use emergency paper ballots. If this 
occurs, the paper ballots are deposited in a special ballot box and are managed at the 
Counting Station using an emergency paper ballot process using the the By-Mail Scanning 
and Resolution module. 
3.8 When the Polling Location Closes 


When the polls close and the Election Judge notifies the system that the last voter has voted, 
the BCS produces three copies of a paper receipt containing a string of numbers that includes 
important auditing data (for example: the BCS ID, the number of access codes issued, the 
number of PVRs cast, the number of provisional ballots cast, the number of 
spoiled/challenged ballots issued, the time the last voter cast a ballot, etc.) and a hash of the 
sum of the entire set of EVRs on the BCS. This number is in human-readable format as well 
as a 1-D barcode. This is called the Election Data Integrity Hash. 


The Election Judge uses an application that resides on the computer at the Voter Check-in 
Station used for qualifying voters. It prompts the Judge to scan the Election Data Integrity 
Hash barcode and transmit this information to the Receiving Substations and Central 
Counting Station. The Election Judge posts one copy of the paper receipt on the door of the 
polling location, retains one copy, and includes one copy with the other election forms 
delivered to the Receiving Substation. 


Using a method (to be recommended by the proposer) such as employing large tamper- 
resistant evidence bags, the Election Judge seals and secures the BCS and a randomly 
selected Voting Station. The Judge seals the opening(s) for the Ballot Box/Scanner and, if 
applicable, the provisional and emergency ballot boxes. Two election workers transport the 
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BCS, a Voting Station, the Ballot Box Scanner, and the provisional and emergency ballot 
boxes (if applicable) to a designated Receiving Substation. 


During Early Voting, a similar process occurs at the end of each day, but law enforcement 
officers deliver the daily audit data, the BCSs, and the Ballot Box/Scanners to the 
Administrator’s office instead of Receiving Substations and the Central Counting Station. At 
the beginning of each day, law enforcement transports these items back to the Early Voting 
locations. The Administrator may choose to return the same Ballot Box/Scanner to an Early 
Voting location each day until it is full and in need of replacement. 


At the Receiving Substation (RSS) on Election Night 


On Election Day, the Administrator utilizes satellite Receiving Substations (RSS) positioned 
throughout the County as collection sites. After the polling locations close, teams of at least 
two poll workers per location drive to a Receiving Substation. There, they transfer custody 
of election documents, the BCS, the Voting Station, the Ballot Box/Scanner, and the other 
sealed ballot boxes (if applicable) to RSS workers. 


A possible scenario is that for each polling location, the RSS worker: 
Validates all seals; 


Prints out a receipt from the Voting Station of the barcode containing the audit information 
and the Election Data Integrity Hash; 


Scans the barcode into the Data Collection and Audit Module on a computer at the RSS. 

This application confirms that the hash code sum of the EVRs pulled from the Voting Station 
at the RSS is identical to the hash code pulled from the BCS at the polling location and 
transmitted to the RSS. The RSS worker reviews the poll workers’ paperwork and enters 
additional data, such as the number of signatures on the poll lists. The RSS worker transmits 
this information along with the Election Data Integrity Hash to the Data Collection and Audit 
Module at the Central Counting Station; 


Presents law enforcement officers with the BCS, the Ballot Box/Scanner with the cast PVRs, 
and the provisional and emergency ballot boxes (if applicable). All of these items are sealed 
at the polling location and remain sealed during the transfer to the Central Counting Station. 
The law enforcement officers make frequent runs to deliver these items to the Central 
Counting Station throughout the night; and 


Electronically transfers all of the encrypted vote results on the Voting Station, validates that 
the hash matches the hash from the BCS receipt above, and transmits the data to the Central 
Counting Station for eventual import into the Tabulator module. After confirming the 
transmission, the RSS worker reseals and secures the Voting Station. 


At the Central Counting Station (CCS) on Election Night 


At the Central Counting Station (CCS), the Election Trustees meet. The Election Trustees 
are a diverse group of individuals from the community who represent civic organizations, 
different political parties, the media, etc. Each Trustee has possession of an electronic device 
that contains a private/public key pair. When a pre-determined minimum number of the 
Trustees sign on to the STAR-Vote™ Trustee System as a group, they are able to jointly 
decrypt the vote tallies and provide verifications for these tallies, as well as supporting audit 
data. 


After the polls close, two different modules collect data. The Data Collection and Audit 
Module collects the Election Data Integrity Hash codes and other information from the 
polling locations and matches them against the information from the Receiving Substations. 
The CCS workers review and compare this data for inconsistencies. 
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RSS workers transmit the election result data from the Receiving Substations to the Data 
Collection and Auditing Module at the Central Counting Station. CCS workers download the 
data from this module onto a write-once data storage device (non-volatile memory device or 
medium) and manually load it into the stand-alone In-Person Voting/Tabulation module 
Tabulator. In the event of transmission problems at an RSS, or if the Administrator wants to 
perform a more thorough check, CCS workers download the data from the physically 
transported BCSs onto a write-once data storage device or directly into the Tabulator for 
comparison and/or use. 


The Trustees decrypt this data for tabulation throughout the night. As tallies are computed, 
CCS workers periodically write the data to a write-once data transfer device and load that 
data onto a separate system. As In Person Voting results become available, the Tabulator 
exports unofficial cumulative and precinct totals to the Results Aggregation module to merge 
this information with the By-Mail results. When all locations are counted, the Tabulator 
module exports final unofficial cumulative and precinct reports for consumption by the 
Results Aggregation module. 


The Tabulator produces several reports for the In-Person Voting/Tabulation module that 
come in a variety of formats. The reports include, but are not limited to, an EVR hash code 
report of the hash computation of results from each location (a comprehensive report of all 
locations and by batch); a comprehensive report of all elections and races; locations 
reported/not reported (comprehensive of all locations and batch reports); the number of votes 
cast per location based on the results data; number of provisional ballots (comprehensive and 
by location); raw data for import into the Results Aggregation module; electronic files that 
are the ballot manifest for each Ballot Box/Scanner; and Bulletin Board postings that are for 
internal use only. 


Ballot-By-Mail Processing 


Processing ballots by mail begins early during the election cycle. The Administrator may 
receive and accept Military and overseas Federal Postcard Applications (FPCAs) at any time 
during a calendar year, and standard ballot by-mail applications between 60 and 11 days 
prior to an election. Long before ballot content is finalized, the Administrator’s Ballot-by- 
Mail staff processes the applications and prepares accompanying materials to ensure a fast 
turnaround as soon as ballots are available. 


A by-mail voter with an accepted standard application receives his or her paper ballot in the 
mail. The voter hand marks his or her choices on the ballot and returns it using the mail or a 
common courier. A person who falls under the Uniformed and Overseas Citizens Absentee 
Voting Act (UOCAVA) and files an FPCA application can opt to receive either a paper 
ballot to hand mark and return by-mail or an emailed electronic image of a ballot to print, 
hand mark, and return by mail. 


Ballots Sent and Returned by Mail: The Early Voting Ballot Board (EVBB) convenes for 
the first time toward the end of the Early Voting period. They inspect, qualify, and perform 
signature validation on all incoming voted by-mail ballots using the outside carrier envelopes 
and any enclosed forms or documents. Once the EVBB accepts a ballot, they separate the 
pink privacy envelope (that holds the voted ballot) from the carrier envelope and place it in a 
ballot box. 


Next, the EVBB opens the ballot box and begins to process the voted ballots. The EVBB 
opens the pink envelopes and reviews each ballot for potential “intent of the voter” conflicts. 
Intent of the voter problems occur when a voter marks his or her ballot in a way that might 
cause the digital scanner to incorrectly record the way the voter intended to vote (for 
example, stray marks on a ballot). On occasion when a ballot arrives torn or otherwise 
damaged, the EVBB must remake the ballot in accordance with election law. 
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The STAR-Vote™ EAC-Certified By-Mail Scanning and Resolution product digitally scans 
the ballots and records voters’ selections. System settings can help to segregate out the 
ballots that need resolution. The EVBB may detect and manually sort ballots for resolution 
by the system, or the Administrator may activate settings, such as detecting undervotes and 
overvotes, that the system automatically pinpoints and resolves. 


The system records actions taken by the EVBB on ballots that require resolution. Whenever 
the EVBB directs an action that requires a change on the system to prepare a ballot for 
tabulation, the system maintains an easily retrievable scanned image of the original ballot 
prior to resolution and an explanation of all changes. 


The Ballot Board convenes several times throughout the election period including Election 
Day/Night and eight days after Election Day to process late FPCA ballots and Election Day 
provisionals. 


Ballots Sent Electronically and Returned by Mail: A UOCAVA voter using an FPCA 
application may request an electronic ballot sent by email that the voter prints, hand marks, 
and returns by mail. When processing the FPCA request, the Administrator inputs the 
application information, including the choice of an email ballot, into the voter record in the 
Voter Registration Ballot-by-Mail Module (not a part of STAR-Vote™). With access to a set 
of PDF ballots from the STAR-Vote™ By-Mail Ballot Generator, the Administrator uses the 
Voter Registration Module to transmit the ballot. The Voter Registration Module bundles the 
PDF ballot image with other required electronic documents and makes them available 
through a secure, voter-specific, online portal. The voter opens the portal and prints the 
documents including the ballot. The STAR-Vote™ By-Mail Ballot Generator assigns and 
prints a unique serial number on the ballot in accordance with the Texas Election Code. The 
voter hand marks the ballot and returns it by mail. The By-Mail Scanning and Resolution 
product must be able to read the unique serial number and directly process this ballot without 
using remake procedures. 


Election Results 

The outcome of the election is reported in a variety of formats that range from summary 
results to detailed views of data down to the precinct level. The By-Mail results are tabulated 
separately from the In Person Voting results and the two are brought together by the Results 
Aggregation function. When the two sets of results are merged, the detailed level combines 
the information at the precinct level such that the By-Mail returns are sorted by precinct to 
match the corresponding precinct returns from the In Person Voting returns. Precinct returns 
list detailed results by voting method and provide cumulative results along with other 
parameters associated with the outcome of the election. Once the returns are aggregated at 
the precinct detail level, the returns are passed to the Report Creation, Formatting and 
Publishing module for formatting the data into a wide variety of report structures for 
publication and distribution. The raw, aggregated data is also used for input to the Election 
Night Reporting application that supports web-based publication of the returns. Reports are 
produced in both paper and electronic format and the electronic versions are posted to the 
Administrator’s website. 


Post-Election Day Processes 


Back Up and Archiving: When the BCSs and Voting Stations are returned to the 
Administrator’s Office, the Administrator backs up and archives the data on all of the 
devices. Should a contest of election or further need for inspection arise, there must be clear, 
easy, and rapid methods for recalling data, records, and reports for use as forensic evidence 
in order to reconstruct and review the entire election, if necessary. 
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Late Mail and Provisional Ballot Processing: After the election, the EVBB convenes for 
the final count and tabulation of accepted late by-mail and provisional ballots, and reviews 
write-in votes for inclusion in the tally. 


Audits: The Administrator examines all data, investigates inconsistencies, performs a risk 
limiting audit to establish statistical confidence that the outcome of the election is accurate, 
and matches a sample number of spoiled/challenged paper records (PVRs) to their 
corresponding electronic vote records (EVRs). 


Canvass Reports: The Administrator finalizes the results and generates the final canvass for 
the election. These reports are marked as “final” or “official.” 


Highlights of STAR-Vote™’s Cryptographic Features 


A sophisticated use of cryptography gives STAR-Vote™ significant layers of security and 
transparency and minimizes the risk for election tampering. In addition, it allows for the use 
of Risk Limiting Audits to provide an even higher degree of confidence that the outcome of 
the election is accurate. 


The use of cryptography in this system offers the following advantages: 
All electronic records are protected with multiple layers of tamper-evidence. 


Sending a hash of vote data from each polling location to the Receiving Substation when the 
polls close provides a way to confirm that tampering is not occurring during the transport of 
the electronic data. 


This information is also a tool that can detect if alterations of the paper vote records are 
attempted. When the polls close, the BCS produces the Election Data Integrity Hash. The 
Voter-Check-in Station computer at the polling location scans the Election Data Integrity 
Hash barcode and electronically sends the information to the Receiving Substations and the 
Central Counting Station. When an Election Judge surrenders custody of the electronic data, 
the Voting Station (randomly selected at the polling location by the poll workers), the BCS 
and the Ballot Box/Scanner at the Receiving Substation, RSS workers print a new hash code 
from the Voting Station. This hash code is compared with and must be identical to the one 
originally sent from the polling location. 


The technique of hash chaining is a key technology for providing electronic tamper evidence. 
Each individual vote record contains a hash of the previous vote record cast on the same 
device on that day. As a result, even a voter who votes after the altered electronic record is 
created and checks his or her ballot can detect whether tampering has occurred. 


An individual or a couple of individuals cannot conspire to decipher the encrypted data. 


A diverse group of individuals from the community (representing civic organizations, 
different political parties, the media, etc.) form a group of Trustees. In a secure environment, 
each of these Trustees generates a private/public key pair, and together they participate to 
generate the Election Public Key. Unless a predetermined minimum number of members of 
the group act together, the vote count cannot be decrypted, and vote data cannot be accessed 
or modified. 


Coded vote counts can be combined so vote totals can be determined without decrypted 
individual ballots. 


The cryptographic system makes use of a property called additive homomorphism. This 
allows the votes to be totaled and audits conducted without the chance of infringing on the 
secrecy of the ballot. When a voter makes his or her choices at the voting station, the 


software uses an algorithm to turn it into an encrypted code. The additive homomorphism 
property makes it possible to combine the encrypted votes and come up with an encrypted 
sum. When that sum is decrypted, it is the same number as the total calculated from the non- 
encrypted data. 


e Accuracy of the totals can be confirmed without decrypting them. The validity of ballot 
contents can be independently checked without divulging voter selections. 


The cryptographic system employs a technology known as commitment consistency. The 
system utilizes NIZK (Non-Interactive Zero Knowledge) proofs throughout to allow 
independent verification (without providing the decryption key) that all ballots correspond to 
the rules of the election (no overvotes/undervotes) and to validate with mathematical 
certainty that the officially-provided tallies are correct decryptions of the vote totals. 
Therefore, an independent observer can check a mathematic proof that the tabulated results 
correctly reflects the totals of the ballots cast by the voters. 


e Patterns cannot be detected in the encrypted codes. 


All encryption makes use of cryptographic randomization in order to make sure that a vote 
for the same candidate on a different ballot does not look the same to an observer. 


e Risk-limiting audits test the accuracy of election outcomes and verify the consistency 
between the Electronic Vote Record (EVR) and the Printed Vote Record (PVR). The 
risk-limiting audit offers two significant advantages. 


First, a risk-limiting audit provides an efficient method to test that the electronic versions of 
voters’ selections (EVRs) match the voter-verified paper records (PVRs) placed into the 
Ballot Box/Scanners. The audit consists of randomly selecting ballot serial numbers 
(PCIDs), locating the PVRs with those PCIDs, and comparing the EVRs to the corresponding 
PVRs. 


Second, it provides statistical confidence that the outcomes of the election are accurate. The 
audit team uses a statistical calculation to determine the number of PVRs that must be 
inspected to prove within a specified margin of error that tabulation correctly reported the 
winners in a race. If two candidates have vote totals that are not close, the audit team checks 
a small number of PVRs to demonstrate with a high degree of certainty that the results 
outcome is correct. If two candidates have vote totals that are close, the team examines a 
higher number of PVRs. If the team finds any discrepancies between PVRs and EVRs, they 
increase the sample size and repeat the process until they complete a round without errors, or 
until they perform a full hand recount. This process also tests the accuracy of the decryption 
and the content of the EVRs. 


e Cryptography allows the public to participate in confirming the accuracy of an election 
through the use of an electronic Bulletin Board accessible at the Election headquarters. 


The Travis County Clerk’s website and every voter’s receipt contains instructions on how to 
access the Bulletin Board. On election night and thereafter, the Bulletin Board posts 
unofficial returns and information regarding the election. This includes a list of the 
encrypted EVRs of all cast ballots. People who have no basic knowledge of cryptography 
and individuals or organizations that do may use this data in a variety of ways. Some 
examples of how they may examine this data are: 


o A voter can verify that his or her ballot is included in the count. 
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After a voter makes his or her selections, the Voting Stations prints a PVR and a separate 
receipt. The receipt contains a mathematically computed number (a hash) that is based on 
the ballot content. Using that number, the voter can look on the Bulletin Board and verify 
that the system correctly read the EVR and included it in the tabulation. This number is not 
on the ballot and can never be used to read the actual ballot content of a cast ballot. 

More importantly, because of the additive homomorphic property of the encryption, 
independent individuals or Entities can take the individual encrypted records that the County 
claims are cast and combine their encrypted votes together to make an encrypted tally. 
Thanks to the commitment consistency already described, an independent Entity can validate 
mathematically that the official tally is a correct decryption of that encrypted tally they have 
independently calculated. By doing so, they have independently verified that every record 
the County claims is cast was actually cast and is part of the final tally. Combined with the 
ability of a voter to look up his or her specific record, this provides unprecedented confidence 
to the voter that his or her votes made it into the official tally. 


A voter or a Parallel Testing Audit Team can perform live, on-site parallel testing to 
make certain that electronic votes are being recorded as voted. This is done through the 
use of “challenged” ballots. 


The procedures for creating a challenged ballot are the same as those for creating a spoiled 
ballot. The voter makes ballot selections but does NOT put the PVR into the Ballot 
Box/Scanner (therefore, not officially casting the ballot). Instead, the voter takes the PVR to 
a poll worker who stamps it as a “Spoiled or Challenged Ballot.” 

After the election, the system decrypts these EVRs that are created but NOT formally 
completed and cast. The Administrator performs an audit by using the PCID on any or all of 
these PVRs to locate (using a search function) the EVRs with a matching hash code. The 
Administrator compares the content of the PVR with the EVR to confirm that the system 
correctly captured the voters’ selections. 

Depending on a state’s guidelines and laws, the Administrator may post the decrypted ballot 
information from the Spoiled/Challenged Ballots on the Bulletin Board for public 
examination. 


An independent party can develop an “app” to validate the vote totals. 


An individual or organization may employ someone with cryptographic skills to develop an 
application that independently calculates an encrypted tally to verify against the official tally 
without ever decrypting the content of the EVRs. The requirements in this proposal include 
the creation of certain components for release as open source to the public. These 
components provide the necessary ingredients for anyone to build an application that 
confirms the correctness of the tallies and the integrity of the encryption. 


Risk-Limiting Audit Support 


STAR-Vote™ employs the use of risk-limiting audits after each election to ensure, with a 
high level of confidence, an accurate outcome of an election. After each election and before 
the final canvass, an audit team performs the risk-limiting audit for the purpose of ensuring 
confidence that there is a perfect 1:1 representation between the electronic vote records 
(EVRs) used to tally the election and the selections stored on the printed vote records (PVRs) 
held in Ballot Box/Scanners. Risk-limiting audits are statistically meaningful audits of the 
outcome, not recounts. 


To enable this goal, the Trustees produce a list after the election that contains a plaintext 
copy of each vote from each EVR. The vote order is randomized so that it is impossible to 
connect a given vote back to any specific EVR without additional information. 


A code is paired with each plaintext vote. This code is a hash of two things: the PCID of the 
page of the PVR on which that vote should appear and the race ID for the race in which that 
vote is cast. A Mix-net produces and distributes the decryption by the Trustees as part of the 
general tabulation/decryption process. The Mix-net, in this instance, must be verifiable (each 
step in the Mix-net must provide a proof that there is a 1:1 correlation between inputs and 
outputs). 


This list represents a commitment to a 1:1 relationship between the individual plaintext votes 
on physical pieces of paper and individual encrypted votes in cast EVRs. The publication of 
this list enables public observers in the Risk Limiting Audit process to use a list they know 
tallies correctly and to which the election authority has committed. 


At the time of the audit, election personnel and public observers gather and generate a 
random seed (employing a method that generates a genuinely random number) and use it to 
seed a pre-specified, publicly available random number generator. 


Election personnel use counting scales to establish the actual number of sheets of paper in 
each ballot box. This provides an upper limit on the number of unexpected PVR pages 
(pages without a corresponding EVR) it is possible to encounter. Using this upper limit, 
knowledge of the number of the margin of victory in each race, and knowledge of which 
races are on which ballot style pages, it is possible to calculate the minimum number of 
pages of each ballot style page type that must be identical to their electronic record in order 
to meet a pre-specified threshold of statistical confidence. A sample implementation of these 
calculations may be found at this url: 


http://www.stat.berkeley.edu/~stark/Vote/auditTools.htm 


Audit support software implements these calculations and, using the random number 
generator seeded earlier, generates a complete list of the ballots to pull for audit in the first 
sample. This is specified, for example, by saying “The page with PCID xxxxxxxx, in ballot 
box yy”. The process of finding the page with the correct PCID in a given ballot box is aided 
through the use of custom-modified high-speed scanners (or similar device) that can make 
use of this data encoded into the barcode of each page. 


When the audit team pulls the PVR, it is shown to the public observers, making its PID 
known. Using this value and the race IDs known to correspond to races on that ballot style 
page, the software calculates all of the hash codes associated with the votes on that page from 
the plaintext list. A quick lookup of these codes should reconstruct the electronic record 
associated with that page perfectly. The team checks theses votes against the selections on 
the printed page. If no discrepancies exist, the audit proceeds to the next randomly selected 
page. If discrepancies exist, the team notes the races in which the discrepancies occurred and 
the impact of the discrepancy on the tally. 


When the team completes its review of the full set of PVRs required by the initial 
calculation, and if all EVRs perfectly match, the team declares the electronic tally as audited 
and statistically consistent with the paper record. If the team finds any errors, they 
recalculate the sample sizes and draw new ballots to reach those larger sample sizes. If the 
team finds successive errors, it repeats the process until either there is a round with no errors 
or a full hand recount of the paper records is completed. 


The following chart illustrates how different audit and security levels are used in STAR- 
Vote™, 
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4.0 Desired Operational and Performance Characteristics 


The following section outlines the desired operational and performance characteristics for the 
STAR-Vote™ system. The paragraphs describe the features, functions and objectives of various 
components of the system and the desired behavior. Some of these items have been converted 
into system requirements in Part II of this RFP; others are informational and convey operational 
and performance objectives of the County. Proposer’s detailed response, requested in Part II, 
should attempt to incorporate the information that follows in applicable sections of the 
Proposer’s response. The evaluation of proposals includes a subjective assessment of Proposer’s 


overall understanding of the system and how well the response embraces the spirit of STAR- 
Vote™, 


4.1 


4.2 


4.3 


Offers the accuracy and speed of an electronic vote count and the accountability of a 
paper ballot. For example: 


4.1.1 The system must provide rapid and accurate electronic vote counts and a paper 
record of each voter”s choices that can be verified by the voter; and 


4.1.2 The system must allow the use of both the electronic and paper records of voters’ 
choices for resolving issues and questions regarding the vote count and for audits 
(including risk-limiting audits), recounts, and contests, while retaining voter 
anonymity. 


Sets a new, higher standard of security for the use of electronic and paper vote records 
and vote counting. For example: 


4.2.1 The system must incorporate extensive security methods such as end-to-end 
verifiability, trusted platform management, and system connection strategies that 
mitigate the risks associated with electronically voted and counted ballots; 


4.2.2 The system must utilize technology and physical security methods to ensure 
electronic and paper vote records are not tampered with from the time voting 
materials leave the polling location to the time they are tallied at the Central 
Counting Station; 


4.2.3 The system must address security risks that include, but are not limited to: the 
introduction of malware or a malicious machine, forging votes at a voting station, 
tampering with a ballot box, ballot box stuffing, chain voting, power or network 
connection disruption, compromise of voter privacy, denial of service, misdeeds 
by election workers/officials, tampering during transport of balloting materials, 
and theft of voting station equipment or ballot boxes; 


4.2.4 The system must offer a means for identifying that a problem has occurred, 
whether accidental or malicious, isolate the area of attack, and provide detailed 
data on the events; 


4.2.5. The system must be built to defend against insider attacks — including attacks both 
from election personnel and from system vendor personnel; and 


4.2.6 The system must be able to prove the accuracy of the results it provides. 


Utilizes new and current methods of transparency at every stage of the process. For 
example: 


4.3.1 The system must provide and promote transparency where possible using non- 
tech, low-tech, and high-tech strategies; 


4.3.2 The system must provide testing processes that ensure the accuracy of important 
components such as ballot language, ballot styles, tabulation, cryptographic 
functions, reporting, management of spoiled and provisional ballots, and audit 
reconciliations. The processes must be thorough, beyond the requirements of the 
law, and openly available for public viewing; 


4.4 


4.5 


4.6 


4.7 


4.3.3 The system must provide a Bulletin Board for internal County use only that still 
promotes transparency and trust in the vote count. This allows the public to 
participate in testing the accuracy of the vote count without violating voter 
privacy. This internal Bulletin Board must be accessible from the Administrator’s 
webpage and must contain a list of encrypted electronic vote records. Voters 
must be able to verify that their ballots were cast and included in the vote count 
by using a code on a receipt printed in the polling location. These codes are hash 
codes that are calculated based on the full content of the ballot but do not allow 
anyone to reconstruct any information about the voters’ selections; and 


4.3.4 The system must give voters interested in participating in the auditing process the 
choice to vote a Spoiled/Challenge ballot in addition to casting a regular ballot. 
Spoiled/Challenge ballots are not included in the final tally process, but are 
included in the group of ballots where all or a sample number are pulled for direct 
comparison with the electronic records after the election. 


Incorporates numerous strategies for auditability throughout the process for every 
election. For example: 


4.4.1 The system must provide efficient and rapid methods for performing audits 
throughout the election cycle to ensure that errors or problems are found, 
documented, and resolved as quickly as possible; 


4.4.2 To reduce the chance of tampering or theft of election equipment prior to the 
opening of the polls and during transportation after the polls have closed, the 
system must provide a means to pinpoint the location of key election equipment 
and detect and mark the time that the seals/locks containing election equipment 
are set and opened; 


4.4.3 The system must incorporate the use of risk-limiting audits, a particularly 
powerful tool providing an independent check to verify the accuracy of an 
election’s outcome. 


Provides the best methods possible for assisting persons with disabilities and meeting 
established accessibility guidelines. For example: 


The system must provide the best methods possible for voting accessibility and be 
versatile enough to adapt to new technologies as they become available to assist persons 
with sight, hearing, and/or mobility challenges. Giving all persons, regardless of 
disability, the chance to vote in the same manner using a secret ballot is of paramount 
importance. 


Provides multiple layers of redundancy to ensure available and reliable sources of data. 
For example: 


4.6.1 The system must have both electronic and paper vote records. The system must 
store the full set of voter choices in a polling location on all Ballot Control 
Stations (BCSs) and on all Voting Stations; and 


4.6.2 The system must have multiple sources available for use in determining the true 
vote count, if a problem occurs in the polling place. 


Has the flexibility to efficiently perform in different election environments. For example: 


4.8 


4.9 


4.7.1 The system must be able to efficiently operate in election situations that include 
Early Voting, Election Day Precinct Voting, and Election Day Vote Centers. This 
includes physical adaptability to a wide variety of polling location environments 
and technical adaptability to a wide range of circumstances; 


4.7.2 The system must be able to manage a variety of needs from those of small polling 
locations to large mega-voting sites; and 


4.7.3 The system must be able to manage a large number of ballot formats and elections 
that include a variety of Entities with potentially different voting options and 
tabulation methods (primaries, straight part voting, and varying choice selection 
instructions). 


Utilizes a Red Team to maximize system security, creates new testing procedures, and 
develops a response plan in the event of an attack. For example: 


4.8.1 The Red Team looks for flaws and vulnerabilities in system design, coding, 
software practices, and implementation. 


4.8.2 The Red Team works in cooperation with the vendor throughout the development 
of the system and provides feedback to the Administrator at the completion of 
each phase of the project. The vendor makes requested improvements before 
moving on to subsequent phases. 


4.8.3 For use during implementation and regular operation of the system, the Red Team 
works in cooperation with the vendor and the Administrator to develop strategies 
to test whether an attack has been attempted; assess the type and degree of any 
damage that occurs; and establish an action plan for stopping an attack, restoring 
operations, and creating documentation on the event. 


4.8.4 The County will separately contract for the services of the Red Team. The 
Administrator will independently select the members of the Red Team. The 
vendors for the other Elements will not participate in the selection of Red Team 
members. 


4.8.5. The Administrator adjudicates disagreements between the vendor and the Red 
Team. 


Incorporates a plan to be used throughout the development process that provides evidence 
that high quality standards were used in the design, development, documentation, and 
implementation were used. 


4.9.1 The system must be well designed; engineered using best practices; secure, robust 
and scalable; usable and accessible; and agile enough to steadily evolve through 
software and hardware upgrades; 


4.9.2 The vendor must implement a plan to measure the successful completion of each 
phase and to demonstrate quality design, in-depth testing, adherence to all laws 
and requirements governing elections systems, the use of best practices, and 
maintenance of thorough and current documentation and version control. 


4.10 Has reasonable development, maintenance, and support costs. For example: 


4.11 


4.12 


4.13 


4.10.1 The system must provide Travis County and other possible STAR-Vote™ 
counties with a voting system that meets their needs while protecting the interests 
of their taxpayers. The system must be designed with efficiency and cost savings 
recognized during all stages of the project - from development to ongoing use; 


4.10.2 The system must have reasonable purchase, maintenance, and support costs; 


4.10.3 The costs for the upgrade of software must be minimal or part of the maintenance 
agreement; 


4.10.4 The costs for replacing or adding hardware must be reasonable; and 
4.10.5 Support services must have variety, depth, and reasonable costs. 


Is developed by vendors with high ethical standards and policies, a history of reputable 
business dealings, a sound financial structure, a depth of required expertise, and a proven 
record for completing large scale, complicated projects on time and within budget. For 
example: 


4.11.1 Vendors working on this project must agree to openness and full disclosure, and 
maintain a very high standard of ethics in fact and perception. It is imperative 
that a project of this size and sensitivity be conducted by vendors who are willing 
and able to withstand a high degree of scrutiny. Travis County and the other 
participating counties are determined to ensure the success of this project, protect 
any invested financial and human resources, and safeguard the trust we have 
earned from the voters; and 


4.11.2 Vendors must provide information to demonstrate throughout the project that they 
are financially sound and can devote the appropriate resources to this project. 


Is designed for the use and evolution of commercially available hardware and associated 
software whenever possible. When it is not possible, the vendor must provide reasonable 
explanations, descriptions, and pricing detail for any proposed proprietary equipment. 
For example: 


4.12.1 To improve costs, voter usability standards, and allow for beneficial 
improvements in technology, the system must make use of commercially 
available hardware and associated software wherever possible; 


4.12.2 Unless no other choice is possible, this RFP discourages proprietary hardware or 
commercially available hardware and associated software packaged in a 
proprietary “box”; and 


4.12.3 The vendor must consider when designing and anticipate to the greatest degree 
possible inevitable changes in platforms, software modifications, and hardware. 


Assumes and plans for effective and efficient change so that the system benefits from 
new technology without requiring reinvention or major overhaul. For example: 


4.13.1 Interoperability is a fundamental principle in the development of STAR-Vote'M, 
When hardware and software technologies change, the system should require 
minimal redesign; 


4.14 


4.15 


4.16 


4.13.2 The system must be adaptable to a variety of platforms, some of which may not 
exist today; 


4.13.3 Modules must be decoupled to the greatest degree possible, and interact only 
using documented file formats, software interfaces, and communication protocols; 
and 


4.13.4 The system must be extensible, and, when possible, every component must be 
interoperable with other versions of the same component from other vendors. For 
example, if the Administrator adopts a new voter registration system or a different 
vendor develops a better variant of the ballot design tools, the Administrator must 
be able to license it from that vendor and integrate it into their STAR-Vote™ 
deployment with little or no modification of STAR-Vote™ code. 


Definitively records voter intent. For example: 


The system requires the use of paper ballots. Those ballots must be marked in such a way 
that the intent of the voter is never in question. The County knows from experience and 
from watching numerous vote contests throughout the nation that in a hand marked, paper 
ballot election, there is always a subset of ballots with ambiguous vote markings. This 
results in a situation where election workers (or the courts) must attempt to discern what 
the voter is trying to indicate. To alleviate this, the system must provide the voter with a 
computer marked and printed record, and give each voter the opportunity to review the 
printed paper record of his or her choices before placing it in the ballot box. 


Employs open standards where possible in software development. For example: 


4.15.1 Wherever possible, the system design must leverage existing, open standards and 
data formats. Where such standards do not exist or are insufficient, the County 
encourages expanding on existing standards and technologies with an eye toward 
establishing a new industry standard or even new published open standards; 


4.15.2 The system must not use any technology, standard, or data format that would 
preclude Travis County (or a consortium of counties) from retaining exclusive 
rights to the system’s source code if it chooses to do so. 


Utilizes technology that is intuitive and familiar to voters, incorporates usability design 
principles for electronic and paper ballots, and allows for an efficient flow through the 
polling place that is friendly and easy to understand. For example: 


4.16.1 The system must use interfaces for the voter that are straightforward and logical 
and technology that is able to process rapidly. The system must utilize equipment 
that has the feel of a technology familiar to most people (for example, a smart 
phone or tablet), and it must help voters accurately record their preferences when 
making ballot selections; 


4.16.2 The flow of voters through the polling location must be intuitive and time 
efficient to ensure that lines are minimized and efficiency maximized; 


4.16.3 Ballot design, with a few exceptions, must follow the guidelines set by Anywhere 
Ballot and AIGA Design for Democracy. These organizations have developed 
standards to improve the way government and citizens communicate and have 


4.17 


4.18 


4.19 


4.20 


made enormous progress in establishing standards for accessible and trusted ballot 
formats; 


4.16.4 The design process should employ User Centered Design (UCD)-based iterative 
design methodologies, with evidence provided of multiple rounds of formative 
evaluation and a report of the summative usability evaluation at the end; and 


4.16.5 In general, systems should be so intuitive that instructions are not required. In 
cases where instructions are required, they should be concise, clear, and 
unambiguous. Pictorial representations may be used, provided they have 
demonstrated 100% understandability. Furthermore, any instructions should be 
delivered when and where they are needed, not in one block at the beginning. 


Uses an electronic system to coordinate and streamline the collection and application of 
ballot language and district/precinct data. For example: 


The system must allow Administrator for election services to work directly in an 
interactive electronic format for the setup and intensive review of the visual and audio 
content of the ballot. 


Allows for the operation of the system independent of the vendor. For example: 


The system must allow the Administrator to operate it entirely without vendor support 
unless maintenance or support is requested or is part of an agreed-upon maintenance plan. 


Is lightweight, durable, and easy for election workers to transport, set up, operate, and 
break down. For example: 


4.19.1 The system’s hardware components and peripherals must be easy to set up and 
break down at the polling location; 


4.19.2 Certain components, such as the BCS and the Voting Stations, must be easy to 
secure and transport in a small car. This implies that all equipment be lightweight, 
mobile, and easy to assemble and disassemble; 


4.19.3. The system hardware must have the strength and durability to remain undamaged 
through frequent handling and transportation; 


4.19.4 Operation of the system must be clear and logical so that a poll worker with one 
day or less of training and limited knowledge in technology can confidently 
manage a polling location; and 


4.19.5 The system must utilize interfaces that help poll workers detect any problems that 
occur and provide instructions on their resolution. 


Produces rapid, versatile, and easily customizable reports. For example: 


4.20.1 The information collected by the system must be easily converted to report 
formats and styles that meet the broad range of needs dictated by the Elections 
Division, media, and the public; 


4.20.2 The system must provide easily customizable reports for a wide variety of 
purposes including the reporting of partial election returns throughout election 
night, final unofficial election returns, and canvass reports; 


4.21 


4.22 


4.23 


4.24 


4.25 


4.26 


4.20.3 The system must produce easily customizable reports containing any audit data or 
other information collected by the system; and 


4.20.4 Data must be organized and exported in a variety of formats including but not 
limited to TXT (tab-delimited), CSV, XLSX, PDF, XML/JSON or other Human 
Readable format and easily uploaded to the Administrator’s Election Night Return 
System, the Texas Secretary of State, the media, and any other customers. 


Ensures voters receive the correct ballot format. For example: 


To minimize or eliminate human error, the system must utilize automated methods to 
provide the voter with the correct ballot format. 


Demonstrates flexibility in the polling place by allowing the continuation of voting in 
disruptive circumstances. For example: 


The proposal must include strategies for sustaining or immediately resuming voting in the 
event of a disruptive situation. Potential issues include but are not limited to total or 
partial loss of power, locked polling locations (requiring relocation or the use of 
emergency paper ballots), equipment failure, and attempted malicious activity. 


Consists of reliable, low cost consumables. For example: 


Proposals must include a list of all consumable supplies necessary for the proper 
operation of the voting system, including estimated usage rates and costs. Proposers must 
consider the ease of replacing these items at any time, especially by election workers in 
the polling place, and the requirements by Texas law that all election records including 
paper records be archived for 22 months. 


Complies with Voluntary Voting System Guidelines (VVSG). 


As currently envisioned, STAR-Vote™ complies with almost all of the elements of the 
2012 Draft VVSG and 2005 VVSG. The County believes a few exceptions are necessary 
to allow for STAR-Vote™’s enhanced security, transparency, auditability, and reliability. 
These are noted in Attachment 2. Any system proposed to fulfill this RFP must fully 
comply with all elements of the 2012 Draft VVSG pertaining to voter interaction and 
accessibility, except for those items listed in Attachment 2 as incompatible with STAR- 
Vote™, 


In addition, the successful proposal must comply with all aspects of the 2005 VVSG 1.0, 
except in such places as discussed in Attachment 2 as not being compatible with STAR- 
Vote™, 


Complies with Federal and Texas Election Laws and Texas Secretary of State Guidelines 
and Advisories. 


As currently envisioned, STAR-Vote™ complies with almost all Federal and State 
requirements. A few exceptions are necessary because of STAR-Vote™’s enhanced 
security, transparency, auditability and reliability. These are noted in Attachment 3. 
Travis County will engage in discussions with Texas Secretary of State to define a 
method for accepting, certifying, and establishing policies for the use of STAR-Vote™. 


Adapts to Changes in Laws and Requirements. For example: 


As technology changes over time, laws and guidelines that govern elections also change. 
Additionally, there is the future potential that many different jurisdictions may want to 
use this system, but they may prescribe very different requirements. This requires that 
every aspect of the system is as easy and low cost to modify or extend as possible, even 
in ways that cannot be anticipated today; that every aspect of the software is designed in a 
modular fashion, using coding best practices including thorough and meaningful 
comments and documentation; and that the system is engineered for straightforward 
extensibility and interoperability with external components. 


NOTE: PARTS II, II, AND IV, ALONG WITH THE PROPOSER’S PROPOSAL, AND ANY 
DEVIATION TO WHICH TRAVIS COUNTY HAS AGREED, IN WRITING, WILL BECOME THE 


CONTRACT. 
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PART II - GENERAL REQUIREMENTS 


SCOPE OF WORK: 


The Travis County Purchasing Agent is requesting competitive proposals from qualified entities for a set 
of components and modules that, collectively, will result in the functional implementation of the first 
phase of STAR-Vote™ as defined in this RFP. The components and modules are: 


Element A: EAC-Certified Modules 

Element B: In-Person Voting/Tabulation and Support Modules 
Element C: Ballot Box/Scanner 

Element D: Red Team Assurance 

Element E: Human Factors Evaluation 


The following general requirements are provided to assist Proposers in understanding the objectives of 
the County and in submitting a thorough response. Specific requirements are provided in the 
Appendices. 


1.1 


1:2 


Applicability of Requirements: The RFP breaks down the requirements into the Elements listed 
above to align the requirements with fields of expertise where the overall goal of the RFP is to 
acquire the entire system defined herein. Only those Proposers who comply with the 
requirements in Appendices A-G will be considered for contract award, and all such 
requirements will be a part of any resulting contracts. However, the RFP does not require all 
Proposers to provide detailed responses to the requirements in Appendices A-G as long as all 
Proposers satisfy those requirements. Detailed responses requirements are given below. 


Detailed Responses for Appendices: Appendices A, B and C break down the system 
requirements into categories that align with the system diagram given in paragraph 3.0 below, 
Appendices D through G provide additional non-functional requirements and Appendices E and 
F provide system-level cryptographic and hardware requirements, respectively. Proposers 
submitting proposals on Elements A, B and C are required to provide detailed responses to the 
Appendices as defined below. Many of the line items in the Appendices do not require 
descriptive responses, but the successful Proposer must acknowledge that the requirement is 
included in its cost proposal. Given this, recommended response types for the line items in the 
Appendices are provided below in an effort to simplify the response. These recommendations 
should be followed if a detailed response is required for a given Element and are as follows: 


1.2.1 Response: Acknowledged; If the line item requirement is accepted and included in the 
cost proposal, no further response is required. 


1.2.2 Response: Acknowledged with interpretation; There are many line items that can be 
implemented in different ways and if the cost proposal assumes a particular 
implementation, a description of the selected implementation must be described. 


1.2.3 Response: Acknowledged with objection; If all or part of the line item requirement 
presents an impediment or support issue, provide alternate wording of the requirement, a 
description of the implementation approach and a justification for the deviation. Only use 
this response option if the intent of the requirement is satisfied. 
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1.2.4 Response: Do not support; If a line item requirement cannot be supported and is not 
included in the cost proposal, state so and provide a reason for the inability to support. 


DETAILED RESPONSE FOR PROJECT MANAGEMENT (All Elements) A description of the 


2.1 


22 


23 


2.4 


2.5 


2.6 


proposed project team, including the number of team members, disciplines, roles and 
responsibilities, and project management practices. The County is providing an enterprise-wide 
system project manager to oversee and coordinate integration of the Elements, so Proposers 
should include a description of how they will interact with this resource. 


Provide high-level project schedule that breaks down any proposed Element into stages of 
implementation and note any dependencies on the availability on other Elements of the RFP. 
Identify key milestones and deliverables for each stage of the proposed Element implementation 
project plan. 


Describe the strategies used to ensure the project remains on schedule and within budget. Also 
provide a description of how schedule issues are discovered and reported to the County. 


Outline test methodologies to ensure deliverables meet the RFP requirements for each proposed 
Element. This should include a description of applied quality assurance practices. Test 
methodologies should include component and system level testing and address whether these 
tests are performed under live or virtual conditions. 


Maintaining update status and progress on each Element will be critical success factor for the 
project. Describe the proposed project status reporting format, frequency and content. 


Describe how changes and modifications to requirements would be managed. 


Describe type of a structure Proposer would suggest for providing on-going support, 
maintenance, and upgrades to the system. 


3.0 OVERVIEW OF MODULES 
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3.1 Summary of Module Functions 


3.1.1 


3.1.2 


EAC-Certified Modules 


3.1.1.1 Election Definition and Ballot Generation Module is a commercially available 
software product that supports current industry requirements for election 
definition and ballot generation function and is certified by the EAC. 


3.1.1.2 Election Definition Export is a utility that is preferably an integrated function 
within the Certified Election Definition Module that generates an Election 
Definition file in a specified format for import into the In-Person 
Voting/Tabulation components. 


3.1.1.3 By-Mail Ballot Generation provides the ability to format By-Mail ballots using 
the Election Definition data into commercially accepted file formats for on- 
demand or batch printing. 


3.1.1.4 Export to Sample Ballot and Web View supports publication of sample ballots 
identified by either precinct or ballot style and in paper and electronic formats. 


3.1.1.5 By-Mail Scanning and Resolution is a commercially available EAC-Certified 
software product that supports current industry requirements for scanning by-mail 
and other paper ballots, allows for digital resolution of hand marked paper and 
write-ins, and generates By-Mail cast vote records. 


3.1.1.6 By-Mail Tabulation is a commercially available EAC-Certified software product 
that supports current industry requirements for tabulation of the By-Mail cast vote 
records produced by the Certified By-Mail Scanning and Resolution Module. 


3.1.1.7 Results Aggregation is a utility that is preferably an integrated function within 
the Certified By-Mail Tabulation Module and combines the By-Mail results and 
In-Person Voting/Tabulation results into a single, unified election results data 
element. 


3.1.1.8 Report Creation, Formatting, and Publishing Module receives the Aggregated 
results and formats and publishes the results in accordance with the requirements 
of the elections division and various consumers including AP, news agencies, and 
other media. 


In-Person Voting/Tabulation modules 


3.1.2.1 Election Definition Import and Finalization module imports electronic and 
audio data, allows files to be locked down for testing, finalizes the Election 
Definition File, and exports the Election Certification Authority used in creating 
1t. 


3.1.2.2 In-Person Ballot Assembly and Generation module is an automated process 
that uses the data contained in the finalized Election Definition file and formats 
the ballot styles for each precinct that will be displayed on the Voting Station. 
This process also generates control files for the BCSs to manage the Voting 
Stations, Ballot Box/Scanners and other logic necessary to conduct In-Person 
voting at Polling Places and Early Voting sites. 


3.1.2.3 Image Creation and Deployment Module takes in the Election Definition File 
and Election Certification Authority; allows configuring (or loading pre- 


3.1.3 


configured) System Images for BCSs, Voting Stations, and Ballot Box/Scanners. 
This module enables provisioning each device permitted to partake in the election, 
pushing the System Image onto that device, and generating and deploying a valid 
certificate for the election to that device (or, rather, having the device generate a 
certificate and signing it). 


3.1.2.4 Precinct System Testing Module provides the ability to test the system in 
standalone, and fully-simulated election scenarios. 


3.1.2.5 In-Person Voting 


3.1.2.5.1 Ballot Control Station (BCS) Module communicates with and 
collects information from all devices in the polling location, makes 
proper ballot styles available on voting stations, manages provisional 
and spoiled/challenged ballots, records votes, and enables poll workers 
to monitor and administer election duties at the polls. 


3.1.2.5.2 Voting Station Module allows in-person voters to select, record, and 
print their ballot choices to paper and receive a printed receipt. 


3.1.2.5.3 Ballot Box/Scanner Module notifies the system when a voter places 
his paper record in the ballot box, creating a record that it has been 
cast. 


3.1.2.6 Data Integration/Validation Module integrates data from polling locations, 
provisional resolution, and performs initial validation on the data. 


3.1.2.7 Trustee Systems Module administers distributed cryptographic processes used 
for tally decryption and generation of audit data. 


3.1.2.8 Tabulator Module administers decryption of tallies and creation of public and 
internal audit data by the Trustees. 


3.1.2.9 Provisional Resolution and Acceptance Module provides a system to register 
each accepted Provisional for inclusion in the final tally. 


3.1.2.10In-Person Voting/Tabulation Reports Module generates a series of reports that 
are specific to In-Person Voting/Tabulation and allows verification/tracking of 
equipment, system performance and results, which become part of the overall 
election audit. 


3.1.2.11 Risk-Limiting Audit Support Module supports the Risk-Limiting Audit by 
generating random samples, reconstructing electronic records for comparison, and 
handling statistics. This module will also support the decryption of all or a 
sample number of Spoiled/Challenged ballots after the election to confirm that the 
paper records match the associated electronic vote records. 


Support Modules 


3.1.3.1 Back Up and Archiving Module This module provides for the storage and rapid 
retrieval of all data captured during an election process. 


3.1.3.2 Sample Ballot and Web View Module creates sample ballots using the same 
software component used to generate election ballot, by ballot style/precinct, a 
comprehensive sample ballot, and sample ballot data for the County Clerk’s 
website. 


3.1.3.3 In-Person Device Initialization and System Load Module deploys a clean 
System Image of the system to each polling location device. 


3.1.3.4 Test Data Generator Module creates combinations of voting data that can be 
compared to the same data manually entered on the system in order to ensure the 
accuracy of the programming. 


3.1.3.5 Audio Ballot Reader allows visually impaired voters to verify their printed 
selections. The Reader scans the text of a Printed Vote Record (PVR) and 
audibly reads the content to a voter utilizing a headset. 


3.1.3.6 Data Collection, Auditing and Testing Module collects audit information and 
the Election Data Integrity Hashes from each polling location at the end of each 
day of Early Voting and at the end of Election Day. At the end of Election Day, 
this information is sent to the Receiving Substations and the Counting Station. 
When the election workers deliver the Voting Stations to the RSS, the data is 
again entered and compared. Data collected from the polling locations and the 
Receiving Substations are also continuously transmitted to the Central Counting 
Station for analysis. At the Counting Station, this data is downloaded and then 
manually loaded into the Tabulator Module. 


3.1.3.7 Bulletin Board Module (internal use only) receives the postings of hash codes 
from the Tabulator/Trustee Control Module and allows voters to look up and 
verify if a ballot is cast. The output of this module will be for internal use only. 


Open Source Reference Modules 


3.1.4.1 Polling Location Network Traffic Inspector Module correctly processes and 
displays all network traffic in a polling location to which it is connected. 


3.1.4.2 Public Audit Data Inspector and Verifier Module consumes the public audit 
data, validates hash chains, and verifies that ballots are well formed. 


3.1.4.3 Ballot Style Definition Inspector Module reads a ballot style definition and 
displays it by correctly using the Ballot UI. 


3.1.4.4 Public Tally Verifier Module consumes the official tallies and the public audit 
data, calculates independent encrypted tallies and, using these, verifies that the 
public audit data successfully verifies all official tallies. 


4.0 


5.0 


DETAILED RESPONSE; ELEMENT A: EAC-Certified Modules 


4.0 


4.1 


4.2 


4.3 


4.5 
4.6 
4.7 


4.8 


Propose a file specification for an Election Definition Export file and a preferred interface for 
exporting data to third-party systems. 


Provide a file specification for a Tabulator import file and a preferred interface for importing 
data from third-party systems into the Results Aggregation utility. 


Provide a functional description of a Results Aggregation utility that accumulates election results 
from two or more voting methods. 


Provide an example ballot generated from the proposed By-Mail Ballot Generation function and 
explain the purpose of any non-election related indicia on the ballot. Detail how the printed 
indicia are controlled and the range of variability afforded. Describe the process for transitioning 
from a test environment to a production environment. 


Propose a structure for providing on-going support, maintenance, and upgrades to the system. 
Outline a process for a Risk-Limiting Audit process for the proposed By-Mail product. 


Outline any limitations of the proposed EAC-Certified product in meeting the requirements 
given in this RFP and propose alternate solutions or workarounds to address any limitations. 


Provide detailed responses to the items in Appendix A and applicable section of Appendices F 
and G. 


DETAILED RESPONSE; ELEMENT B: In-Person Voting/Tabulation and Support Modules 


5.1 


5.2 


5.4 


5.5 


5.6 


5.7 


Propose a file specification for an Election Definition import file and a preferred interface for 
importing data from a third-party system. 


Propose a file specification for a Tabulator export file and a preferred interface for exporting the 
data to third-party systems into the Results Aggregation utility. To simplify the design, 
development and testing of Element B, the RFP is requesting successful proposers to choose and 
propose specific COTS hardware to satisfy the requirements for the various hardware 
components identified in the RFP. Identify the selected COTS hardware computing platform(s) 
and devices for all functions within Element B, justify the selections, name the manufacturer, 
model and the process for quantity acquisition. 


Provide a written hardware upgrade plan that projects selected COTS hardware computer 
platform(s) end-of-life and outlines alternate or new make and model for hardware replacement. 


The successful Proposer for Element B is required to work with the Red Team from Element D. 
Provide an outline of a plan for working with the Red Team. 


Describe the various technologies proposed to be used during any development, including: 
programming language(s)/software libraries; test frameworks; algorithms (where these aspects 
are unusual or important to the design, including the selected cryptographic algorithms); and 
software backend for web-services and any implied hosting requirements. Reference items from 
Appendix D where possible. 


Describe Proposer’s approach to system and software design. Include any development tools 
and methodologies employed to ensure this project is engineered using best practices and that the 
resulting system is secure, robust, and scalable. Reference items from Appendix D where 
possible. 


6.0 


5.8 


5.9 
5.10 
5.11 


5.12 


5.13 


5.14 


5.15 


Describe the process and any tools used for configuration management for control of source 
code, methods for continuous integration for automated build and testing and any tools used for 
defect tracking and reporting. Also address methods used for version control and tracking of 
documentation. 


Describe the process for transitioning from a test environment to a production environment. 
Propose a structure for providing on-going support, maintenance, and upgrades to the system. 


Equipment in the polling location must remain operational on battery power for at least four 
hours. A full precinct must be able to be operated by the power provided by a typical gas-power 
generator supplying about 2000 watts. Propose a test protocol to demonstrate this system 
capability. 


Propose a file specification and transfer method for a configuration import file produced by the 
In-Person Voting/Tabulation Election Definition Import and Finalization module to initialize the 
Ballot Box/Scanner prior to the election to meet the functional and operational requirements and 
descriptions for the Ballot Box/Scanner as defined in this RFP. 


Propose a bi-directional data interface between the Ballot Control Station (BCS) and the Ballot 
Box/Scanner (Element C). 


Propose a data file specification and interface for transferring the Ballot Box/Scanner election 
data following the close of polls to the Back Up and Archiving module defined in Element B of 
this RFP. 


Proposals must include a list of all consumable supplies necessary for the proper operation of the 
voting system, including estimated usage rates and costs. Provide detailed responses to the items 
in Appendix B, C, D, E and applicable sections of Appendix F and G. 


DETAILED RESPONSE; ELEMENT C: Ballot Box/Scanner 


6.0 


6.1 


6.2 


6.3 


6.4 


6.5 


Propose a file specification and transfer method for a configuration import file produced by the 
In-Person Voting/Tabulation Election Definition Import and Finalization module to initialize the 
Ballot Box/Scanner prior to the election to meet the functional and operational requirements and 
descriptions for the Ballot Box/Scanner as defined in this RFP. 


Propose a bi-directional data interface between the Ballot Control Station (BCS) (from Element 
B) and the Ballot Box/Scanner. 


The successful proposer for Element C is required to work with the Red Team from Element D. 
Provide an outline of a plan for working with the Red Team. 


Describe the various technologies proposed to be used during any development, including: 
programming language(s)/software libraries; test frameworks; algorithms (where these aspects 
are unusual or important to the design, including the selected cryptographic algorithms); and 
software backend for web-services and any implied hosting requirements. 


Describe Proposer’s approach to system and software design. Include any development tools 
and methodologies employed to ensure this project is engineered using best practices and that the 
resulting system is secure, robust, and scalable. Reference items in Appendix D where 
appropriate. 


Describe the process and any tools used for configuration management for control of source 
code, methods for continuous integration for automated build and testing and any tools used for 
defect tracking and reporting. Also address methods use for version control and tracking of 
documentation. 


7.0 


6.6 


6.7 


6.8 
6.9 


Propose a data file specification and interface for transferring the Ballot Box/Scanner election 
data following the close of polls to the Back Up and Archiving module defined in Element B of 
this RFP. 


Ground-up development : If proposing the development of a new Ballot Box/Scanner hardware 
device (Option 1 from Appendix 10, section 10.9), provide the following: 


6.7.1 Rendering of the proposed mechanical design and a description of the mechanical 
functions; 


6.7.2 Describe the electrical and mechanical design, engineering, development and testing 
process. Testing should include mechanical stress testing and highly accelerated life 
testing. 


6.7.3 Describe an interim solution for processing PVRs including the mechanical configuration 
and software interface. 


6.7.4 Outline of the manufacturing process and cost of goods once in production. An initial 
production run of 500 units should be used to calculate cost projections. 


Describe the process from transitioning from a test environment to a production environment. 


Propose a structure for providing on-going support, maintenance, and upgrades to the 
systemProvide detailed responses to the applicable items in Appendices D, E, F and G.. 


DETAILED RESPONSE; ELEMENT D: Red Team Assurance 


7.0 


7.1 


71.2 


7.3 


7.4 


7.5 


7.6 


Vel 


Propose a skeleton threat model for election operations and outline its application to the STAR- 
Vote™ system. 


Outline the process and content of an end-to-end risk assessment of the STAR-Vote™ system as 
defined by the requirements in this RFP. Cite any requirement that can be modified to reduce 
risk or any requirement that cannot be validated within the scope of the contract. 


Describe the process used to create a prioritized list of security improvement recommendations, 
required inputs and expected outputs. Discuss general categories within the recommendations 
that are expected given the STAR-Vote™ architecture. 


Provide a list of recommended assurance-related testing and validation techniques, a description 
of each, how they are applied to the STAR-Vote™ system and, the value each provides for the 
overall system security posture. 


Outline Proposer’s recommended secure design principals, their application to STAR-Vote™ 
software development requirements and how these principals are integrated into the process used 
by the successful Proposers of Elements B and C. 


Describe how secure development support will be provided to other contract awardees for this 
RFP. 


Given Proposer’s knowledge of the product development lifecycle, develop a schedule of Red 
Team Assurance tasks with dependencies on the availability of the various STAR-Vote™ 
modules. 


The successful Proposer for Element D is required to work with the successful proposers from 
Elements B and C. Provide an outline of a plan for working with these Element contractors. 


7.8 


7.9 


The Red Team Assurance contract that may be awarded under this RFP covers the development, 
testing and release of the STAR-Vote™ system and does not include election support, review or 
analysis of the system following its deployment and implementation. Propose a program of on- 
going security support for the STAR-Vote™ system and estimated costs. 


Recommend additional security efforts, if any, that are applicable to the Red Team Assurance 
function. 


8.0 


9.0 


DETAILED RESPONSE; ELEMENT E: Human Factors Evaluation 


8.0 


8.1 


8.2 


8.3 


Given Proposer’s knowledge of the product development life cycle, the requirements and 
structure of this RFP and principles of User Centered Design (UCD), describe the method 
recommended to embed UCD practices in the development efforts contemplated by this RFP. 


Review the RFP requirements and make prioritized list of changes or additions to improve the 
usability and accessible of the STAR-Vote™ system. For the top five (5) priority items, discuss 
the process to implement these items and trade-offs for the development timeline. 


Provide an outline of a usability study or series of studies to assess the level usability and 
accessibility with the objective of discovering improvements for the STAR-Vote™ performance 
and operation relative to these qualities. The outline should include estimates of the number/type 
of people required to conduct this program, number and profiles of participants and the required 
equipment and/or systems. 


Describe the process required and development impact for a human factors evaluation to 
incorporate the Performance Protocol and Voting Common Industry reporting cited in Part I, 
Section E, paragraph 2.8. Responses should demonstrate Proposer’s knowledge of the protocol 
and reporting format. Recommend additional resources to augment the aforementioned 
resources and assess the added value of any recommendations. The Human Factors Evaluation 
contract that may be awarded under this RFP covers the development, testing and release of the 
STAR-Vote™ system and does not include election support, review or analysis of the system 
following its deployment and implementation. Propose a program of on-going Human Factors 
evaluation support for the STAR-Vote™ system and estimated costs. 


CONTRACTOR REQUIREMENTS 


In this section and in subsequent sections, each successful Proposer (if any) may also be referred to as a 
“Contractor.” Contractor shall: 


9.0 


9.1 


9:2 


9.3 


9.4 


9.5 
9.6 


Warrant that all goods supplied to County are of the latest models and versions, in good working 
order, free from defects, and in performance to manufacturers specifications. All equipment must 
conform to the manufacture’s official published specifications. 


Agree to repair, adjust and/or replace (as determined by the County to be in its best interest) any 
defective equipment within the warranty period at the successful Vendor’s sole expense, 
including labor to remove defective equipment and install, configure and test replacements. 


Follow manufacturer’s best practices for installing, configuring and documenting services 
provided to County. 


Provide pricing for all required hardware, software, installation, configuration, accessories, 
system warranty and post-warranty maintenance support. 


Perform in a timely manner, the services and activities described within this RFP, in accordance 
with the terms and conditions and in compliance and all other statements made by the Contractor 
in its RFP response. 


Indicate if specialist staff members are full-time employees or contracted. 


Include any innovative/creative service or approach ideas that may reduce the County’s overall 
costs. 


10.0 


9.7 


9.8 


9.9 


9.10 


9.11 


9.12 


9.13 


Provide any suggestions with cost estimates, if applicable, beyond the stated services that would 
provide improved efficiency or beneficial service enhancements. 


Coordinate with the County Clerk or designee on all specified work and sequencing of tasks, 
milestones and testing for project-related efforts that involve two or more contractors. 


Consent to cooperating and coordinating with County-provided project management resources 
and advisors for system-level matters and assistance in managing the operational relationship 
between contractors provided with awards as a result of this RFP. 


Agree to negotiate, in good faith, the format of data interchange requirements between 
components or modules of the system that exist between the defined Element boundaries. The 
negotiations will also include designation of specific contractors for on-going maintenance and 
revision control of the data interchange formats and configuration. Travis County acknowledges 
the final, agreed-upon data interchange format can impact pricing and Contractors will be 
allowed submit a justification for any price increase using their proposed format submitted from 
paragraphs 4.0, 5.0 and 6.0 above. 


Provide all services in accordance with applicable federal, state and local laws, rules and 
regulations, and in a manner consistent with generally accepted professional and technical 
standards of the election industry, software industry or other similar service industries except as 
otherwise stated in this RFP. 


Assign a qualified Project Manager to the project. County has the right to approve in advance in 
writing all Contractor staff assigned at any time to this project, which approval shall not be 
unreasonably withheld or delayed. Contractor’s Project Manager must successfully manage the 
proper performance of Contractor's-obligations as stated in this RFP and any executed contract 
resulting from this RFP. Except in emergency circumstances,. Contractor must not reassign or 
replace assigned staff without County's prior written consent, which will not be unreasonably 
withheld or delayed. Contractor must replace any staff member with an equally qualified’ person 
reasonably satisfactory to County. County is not be responsible for any costs associated with 
changes in Contractor staff. 


Each individual software application or software system and custom-designed electromechanical 
devices must be documented in a Functional Requirements document that consists of testable 
requirements. The Functional Requirements document includes a definition of any interface 
with other components of the STAR-Vote™ system. 


CONTRACT REQUIREMENTS 


Contract must allow for the following requirements as applicable to specific Elements: 


10.1 
10.2 
10.3 
10.4 
10.5 


Acquisition of system and application software, software licenses, maintenance and support 
Hardware purchases, maintenance, and support 

Identification of per hour rate for Contractor’s technical resources 

Identification of per hour rate for Project Management services 


Process for support of changes to system requirements over the term of the contract that includes 
a method of determining any cost impacts to the contract. 


11.0 


MAINTENANCE/SERVICE LEVEL REQUIREMENTS: ELEMENTS A, B and C 


11.1 


11.2 


11,3 


11.4 
11.5 


A service level agreement (SLA) that will include but is not limited to response to and resolution 
expectation for different levels of problem severity. 


Phone support from 8:00am to 5:00pm Central Time for non-election periods, which is defined 
as 18 days prior to any election day and 3 days following any election day. On-site technician 
support given five (5) days’ notice from the County. 


Phone support from 7:00am to 7:00pm Central Time during election periods and one-hour 
response for technician on-site for first three elections. This includes replacement of any 
defective hardware under warranty. 


All software upgrades and updates shall be provided during maintenance period. 


Electronic quarterly and annual reports for all reported problems by: product line, severity, 
description of problem, resolution and length of time to resolve the issue. 


1.0 


2.0 


3.0 


4.0 


5.0 


6.0 


PART III - SPECIAL PROVISIONS 


TERM OF CONTRACT: The term of the resulting contracts will be specific to each Element and will 
accommodate the dependencies that exist between the Elements. It is expected that the schedule critical 
path with the development and testing of Element B (and, therefore, the schedule for the remaining 
Elements) will be dependent on Element B milestones and completion. The County will perform the 
systems analysis necessary to coordinate the schedules of the individual Elements. The recommended 
system-wide schedule will be shared with each successful Proposer during contract negotiation, adjusted 
as necessary when the final contract terms have been agreed to by the parties to each contract. The 
resulting contracts will be subject to the approval of Commissioners Court and will be effective upon 
award. 


OPTION TO EXTEND: Successful Proposers of each Element will agree to an automatic contract 
extension of six (6) months that may be exercised at the County’s option (individually, an “Option to 
Extend” and collectively, the “Options to Extend”), and all provisions of the contracts, except for term 
and price, shall remain unchanged and in full force and effect. County shall exercise an Option to 
Extend no sooner than ninety (90) days prior to expiration of the then current term. County shall have 
the right to exercise all or a portion of the Option to Extend in any combination it deems necessary. 


TERM OF WARRANTY: The successful proposer for Element B shall provide the maximum 
warranty offered by the COTS manufacturer (not less than one (1) year). Warranty shall begin after 
installation is complete, the system is fully tested and operational and accepted by County. During the 
warranty period the Contractor is responsible for labor, materials, and other costs associated with 
required warranty repair. All successful proposers for each Element will warrant their goods and service 
in the body of their respective responses and the final, individual Element warranties will be subject to 
discussion and negotiation during final contract negotiations. 


MAINTENANCE FEES: For each year after the warranty period, the annual license/maintenance fee 
may not increase more than 3% annually. Details of maintenance support must be described in the 
proposal, and must include hours of maintenance support and a statement of what additional charges, if 
any, will be imposed if an on-site visit is required. 


PURCHASE ORDER: Contractor will not release any items or perform any services until a purchase 
order number is assigned by the designated representative of the County Purchasing Office. Contractor 
will reference contract and purchase order on all invoices submitted to the Travis County Auditor. Upon 
issuance of a purchase order, the contract administrator will call the contractor with instructions to 
commence the contracted work. 


CONTRACT ADMINISTRATOR: — For purposes of monitoring performance, establishing 
requirements, approving and coordinating schedules, users, and equipment, the county department 
named below shall act as contract administrator on behalf of Travis County: 


Travis County Clerk 
Ron Morgan (or successor or designee) 
5501 Airport Blvd 
Austin, Texas 78751 
(512) 854-9188 


7.0 


8.0 


IMPLIED SERVICES: If any services, functions or responsibilities not specifically described in the 
contract are required for the proper performance and provision of the project services, they shall be 
deemed to be implied by and included within the scope of the required services to the same extent and in 
the same manner as if specifically described in the contract. Except as otherwise expressly provided in 
the contract, Contractors shall be responsible for providing the facilities, personnel and other resources 
as necessary to provide the project services. 


TRAVEL NOT INCLUDED AS PART OF SOLICITATION: All travel requires prior approval 
from the County Clerk or designate. All approved travel is subject to compliance with Travis County 
travel policies. Travis County will not reimburse Contractor for expenses incurred for any unapproved 
travel or for expenses for approved travel outside the parameters of County policy. 


1.0 


PART IV - GENERAL PROVISIONS 


GENERAL DEFINITIONS: 

1.1 "Auditor" means the Travis County Auditor or her designee. 

1.2 "Commissioners Court" means Travis County Commissioners Court. 

1.3 "County Building" means any County owned buildings and does not include buildings leased by 

County. 

1.4 "Was doing business" and "has done business" mean: 

1.4.1 Paying or receiving in any calendar year any money or valuable thing which is worth 
more than $250 in the aggregate in exchange for personal services or for the purchase of 
any property or property interest, either real or personal, either legal or equitable; or, 

1.4.2 Loaning or receiving a loan of money; or goods or otherwise creating or having in 
existence any legal obligation or debt with a value of more than $250 in the aggregate in 
a calendar year; 

but does not include 

1.4.3 Any retail transaction for goods or services sold to a Key Contracting Person at a posted, 
published, or marked price available to the public, 

1.4.4 Any financial services product sold to a Key Contracting Person for personal, family or 
household purposes in accordance with pricing guidelines applicable to similarly situated 
individuals with similar risks as determined by Contractor in the ordinary course of its 
business; and 

1.4.5 A transaction for a financial service or insurance coverage made on behalf of Contractor 
if Contractor is a national or multinational corporation by an agent, employee or other 
representative of Contractor who does not know and is not in a position that he or she 
should have known about the Contract. 

1.5 "Key Contracting Person" means any person or business listed in Exhibit A to the Ethics 

Affidavit. 

1.6 "Purchasing Agent" means the Travis County Purchasing Agent. 
1.7 "County" means Travis County, Texas, a political subdivision of the State of Texas. 
1.8 "Historically Underutilized Business" or "HUB" means any entity or association formed to make 


a profit in which one (1) or more persons who are educationally or economically disadvantaged 
because of their identification as members of one of the following groups: African Americans, 
Hispanic Americans, Asian Pacific Americans, Native Americans or Women of any ethnicity 
have the following rights: 


2.0 


3.0 


4.0 


1.8.1 Own at least fifty-one percent (51%) of all classes of shares or other equitable securities 
and have incidents of ownership, including an interest in profit and loss, equivalent to the 
percentage of capital, equipment or expertise contributed to the business where 
ownership is measured as though the community property interest of a spouse is the 
separate property of that spouse, if both spouses certify in writing that the non- 
participating spouse relinquishes control over his or her spouse, and his or her community 
property, and not as if it is subject to the community property interest of the other spouse; 
and 


1.8.2 have a proportionate interest and demonstrated active participation in the control, 
operation and management of the business's affairs; where control means having 
recognized ultimate control over all day-to-day decisions affecting the business, and is be 
known to, and at least tacitly acknowledged in day-to-day operations by employees of the 
business and by those with whom business is conducted, and holding a title 
commensurate with that control. 


GENERAL CONDITIONS: 


Contractor represents that he has thoroughly examined the drawings, specifications, schedule, 
instructions and all other contract documents. Contractor has made all investigations necessary to be 
thoroughly informed regarding plant and facilities for delivery of material, equipment and/or services as 
required by the proposal conditions. 


CONTRACTOR CERTIFICATIONS: 


3.1 Contractor certifies that he is a duly qualified, capable, and otherwise bondable business entity, 
that he is not in receivership or contemplates same, and has not filed for bankruptcy. He further 
certifies that the company, corporation or partnership is not currently delinquent with respect to 
payment of property taxes within County. 


3.2 Contractor warrants that all applicable copyrights and licenses which may exist on materials used 
in this contract have been adhered to and further warrants that County shall not be liable for any 
infringement of those rights and any rights granted to County shall apply for the duration of the 
contract. Contractor shall indemnify County, its officers, agents and employees from all claims, 
losses, damages, causes of action and liability of every kind including expenses of litigation, and 
court costs and attorney fees for damages to any person or property arising in connection with 
any alleged or actual infringement of existing licenses or copyrights applicable to materials used 
in this contract. 


DISPUTES AND APPEALS: 


The Purchasing Agent acts as the County representative in the issuance and administration of this 
contract in relation to disputes. Any document, notice, or correspondence not issued by or to the 
Purchasing Agent or other authorized County person, in relation to disputes is void unless otherwise 
stated in this contract. If the Contractor does not agree with any document, notice, or correspondence 
issued by the Purchasing Agent, or other authorized County person, the Contractor must submit a 
written notice to the Purchasing Agent within ten (10) calendar days after receipt of the document, 
notice, or correspondence, outlining the exact point of disagreement in detail. If the matter is not 
resolved to the Contractor’s satisfaction, Contractor may submit a written Notice of Appeal to the 
Commissioners Court, through the Purchasing Agent, if the Notice is submitted within ten (10) calendar 
days after receipt of the unsatisfactory reply. Contractor then has the right to be heard by 
Commissioners Court. 


5.0 


6.0 


7.0 


FUNDING: 

Funds for payment on this Contract have been provided through the County budget approved by 
Commissioners Court for this fiscal year only. State of Texas statutes prohibit the obligations and 
expenditure of public funds beyond the fiscal year for which a budget has been approved. However, the 
cost of items or services covered by this Contract is considered a recurring requirement and is included 
as a standard and routine expense of County to be included in each proposed budget within the 
foreseeable future. County Commissioners expect this to be an integral part of future budgets to be 
approved during the period of this Contract except for unanticipated needs or events which may prevent 
such payments against this Contract. However, County cannot guarantee the availability of funds, and 
enters into this Contract only to the extent such funds are made available. The fiscal year for County 
extends from October Ist of each calendar year to September 30th of the next calendar year. 


FUNDING OUT: 


Despite anything to the contrary in this Contract, if, during budget planning and adoption, 
Commissioners Court fails to provide funding for this Contract for the following fiscal year of County, 
County may terminate this Contract after giving Contractor thirty (30) days written notice that this 
Contract is terminated due to the failure to fund it. 


INVOICING/PA YMENTS: 


7.1 Contractor shall provide County with an Internal Revenue Form W-9, Request for Taxpayer 
Identification Number and Certification, that is completed in compliance with the Internal 
Revenue Code and its rules and regulations before any Contract funds are payable. 


7.2 Payments will be made by ACH/EFT or check upon satisfactory delivery and acceptance of 
items and Contractor’s submission of a correct and complete invoice to the address below: 


Nicki Riley, CPA 

Travis County Auditor 

and 

Emailed to: AP@traviscountytx.gov (preferred method); or 
Mailed to: P.O. Box 1748; Austin, Texas 78748 


For assistance on setting up electronic payments (by ACH), which permits County to directly 
deposit payments into your account, please contact the Travis County Auditor’s Office, 
Disbursements Division at (512) 854-9125. 


In addition, a copy of the invoice must be sent to: 


Denise Bell (or successor or designee) 
Travis County Clerk 
5501 Airport Blvd. 
Austin, Texas 78751 
(512) 854-3997 


7.3 To be considered correct and complete, invoices will include: 


8.0 


9.0 


10.0 


11.0 


12.0 


7.3.1 Name, address, and telephone number of Contractor, which will match the W-9 Contractor 
submits to the Travis County Auditor’s Office (“Auditor”); and name and address of where 
payment is to be sent, if payment is to be by check; 


7.3.2 County Contract or Purchase Order number; 
7.3.3 Identification of products or services as outlined in the Agreement; 
7.3.4 Quantity or quantities, applicable unit prices, total prices, and total amount; and 


7.3.5 Any additional payment information called for by the Agreement. County will not pay 
invoices that are in excess of the amount authorized by the Agreement. 


7.3.6 Payment will be deemed to have been made on the date of mailing of the check or 
warrant. For purposes of payment discounts, time will begin upon satisfactory delivery of 
products and services or submission of acceptable invoice, whichever is last. Partial payments 
will not be made unless specifically requested and approved by County prior to Agreement 
award. 


7.4 Accrual and payment of interest on overdue payments is governed by Texas Government Code 
Chapter 2251. 


RESERVED: 
DISCOUNTS: 


Prompt payment discounts will not be considered in determining low proposals and making awards. In 
connection with any discount offered, time will be computed from the date of receipt of supplies or 
services or from the date a correct invoice is received, whichever is the later date. Payment is deemed to 
have been made on the date of mailing of the check, or warrant. 


OFFICIALS NOT TO BENEFIT: 


If a member of the Commissioners Court belongs to a cooperative association, the county may purchase 
equipment or supplies from the association only if no member of the Commissioners Court will receive 
a pecuniary benefit from the purchase, other than as reflected in an increase in dividends distributed 
generally to members of the association. 


COVENANT AGAINST CONTINGENT FEES: 


The Contractor warrants that no persons or selling agency has been retained to solicit this Contract upon 
an understanding for a commission, percentage, brokerage, or contingent fee, excepting bona fide 
employees or bona fide established commercial selling agencies maintained by the Contractor to secure 
business. For breach or violation of this warranty, County shall have the right to terminate this Contract 
without liability or in its discretion to, as applicable, add to or deduct from the Contract price for 
consideration, or otherwise recover, the full amount of such commission, percentage, brokerage, or 
contingent fee. 


ASSIGNMENT: 


12.1 Assignment. The parties to this Contract shall not assign any of the rights or obligation under 
this Contract without the prior written consent of the other party. No official, employee, 


13.0 


14.0 


15.0 


representative or agent of County has the authority to approve any assignment under this 
Contract unless that specific authority is expressly granted by Commissioners Court. 


12.2 Successors Bound. The terms, provisions, covenants, obligations and conditions of this Contract 
are binding upon and inure to the benefit of the successors in interest and the assigns of the 
parties to this Contract if the assignment or transfer is made in compliance with the provisions of 
this Contract. 


12.3 Ifa change of name is required, the Purchasing Agent shall be notified immediately. No change 
in the obligation of or to Contractor will be recognized until it is approved by Commissioners 
Court. 


FORCE MAJEURE: 


If the performance by the County of any of its obligations hereunder shall be interrupted or delayed by 
any occurrence not occasioned by its own conduct, whether such occurrence be an act of God or the 
result of war, riot, civil commotion, sovereign conduct, or the act or conduct of any person or persons 
not a part hereto, then it shall be excused from such performance for such period of time as is reasonably 
necessary after such occurrence to remedy the effects thereof. 


TERMINATION FOR DEFAULT: 


Failure by either County or Contractor in performing any provisions of this Contract shall constitute a 
breach of Contract. Either party may require corrective action within ten (10) calendar days after date of 
receipt of written notice citing the exact nature of the other's breach. Failure to take corrective action or 
failure to provide a satisfactory written reply excusing such failure within the ten (10) calendar days 
shall constitute a default. The defaulting party shall be given a twenty (20) calendar day period within 
which to show cause why this Contract should not be terminated for default. Commissioner’s Court may 
take whatever action as its interest may appear, resulting from such notice. All notices for corrective 
action, breach, default or show cause shall be issued by the Purchasing Agent or County Attorney only 
and all replies shall be made in writing to the Purchasing Agent at the address provided herein. Notices 
issued by or to anyone other than the Purchasing Agent or County Attorney shall be null and void, and 
shall be considered as not having been issued or received. County reserves the right to enforce the 
performance of this Contract in any manner prescribed by law in case of default and may contract with 
another party with or without competition or further notification to the Contractor. As a minimum, 
Contractor shall be required to pay any difference in the cost of securing the products or services 
covered by this Contract, or compensate for any loss or damage to the County derived hereunder should 
it become necessary to contract with another source because of his default, plus reasonable 
administrative costs and attorney's fees. In the event of Termination for Default, County, its agents or 
representatives, shall not be liable for loss of any profits anticipated to be made hereunder. 


TERMINATION FOR CONVENIENCE: 


County reserves the right to terminate this Contract upon thirty (30) calendar days written notice for any 
reason deemed by Commissioners Court to serve the public interest, or resulting from any governmental 
law, ordinance, regulation, or court order. In the event of such termination the County shall pay the 
Contractor those costs directly attributable to work done or supplies obtained in preparation for 
completion or compliance with this Contract prior to termination; provided, however, that no costs shall 
be paid which are recoverable in the normal course of doing business in which the Contractor is 
engaged. In addition, no costs which can be mitigated through the sale of supplies or inventories shall be 
paid. If County pays for the cost of supplies or materials obtained for use under this Contract, said 
supplies or materials shall become the property of County and shall be delivered to the FOB point 


16.0 


17.0 


18.0 


19.0 


shown herein, or as designated by the Purchasing Agent. County shall not be liable for loss of any 
profits anticipated to be made hereunder. 


CHANGES: 


16.1 


16.2 


16.3 


16.4 


Unless specifically provided otherwise in this Contract, any change to the terms of this Contract 
or any attachments to it shall be made by written change order signed by both parties. The 
Purchasing Agent may at any time, by written document, make changes within the general scope 
of this Contract in any one of the following: 


16.1.1 Description of services; 


16.1.2 Place of delivery; 16.1.3 Any aspect of contract to correct errors of a general 
administrative a nature or other mistakes, the correction of which does not affect the 
scope of the contract and does not result in expense to the Contractor. 


It is acknowledged by Contractor that no officer, agent, employee or representative of County has 
any authority to change the scope of this Contract or any attachments to it unless expressly 
granted that authority by the Commissioners Court. 


If any change under 16.1 causes an increase or decrease in the cost, or time required for 
performance of any part of the work under this Contract, the Commissioners Court shall make an 
equitable adjustment in the contract price, the delivery schedule, or both, and modify this 
Contract. The Contractor must submit any "proposal for adjustment" within thirty (30) calendar 
days after the date of receipt of the written order. 


Contractor shall submit all requests for alterations, additions or deletions of the terms of this 
Contract or any attachment to it to the Purchasing Agent. The Purchasing Agent shall present 
Contractor's requests to Commissioners Court for consideration. 


COUNTY ACCESS: 


Contractor agrees to maintain appropriate accounting records of costs, expenses, and payrolls of 
employees working on the project, together with documentation of evaluations and study results 
for a period of five years after final payment for completed services and all other pending matters 
concerning the Contract have been closed. 


SUBCONTRACTS: 


18.1 


18.2 


Contractor shall not enter into any subcontracts for any service or activity relating to the 
performance of this contract without the prior written approval or the prior written waiver of this 
right of approval from County. It is acknowledged by Contractor that no officer, agent, 
employee or representative of County has the authority to grant such approval or waiver unless 
expressly granted that specific authority by the Commissioners Court. 


If a subcontract is approved, Contractor must make a "good faith effort” to take all necessary and 
reasonable steps to ensure HUBs maximum opportunity to be subcontractors under this Contract. 
Contractor must obtain County approval of all proposed HUB subcontractors through the 
Purchasing Agent. Failure by Contractor to make a good faith effort to employ HUBs as 
subcontractors constitutes a breach of this Contract and may result in termination of this 
Contract. 


MONITORING: 


20.0 


21.0 


County reserves the right to perform periodic on-site monitoring of Contractor's compliance with the 
terms of this Contract, and of the adequacy and timeliness of Contractor's performance under this 
Contract. After each monitoring visit, County shall provide Contractor with a written report of the 
monitor's findings. If the report notes deficiencies in Contractor's performances under the terms of this 
Contract, it shall include requirements and deadlines for the correction of those deficiencies by 
Contractor. Contractor shall take action specified in the monitoring report prior to the deadlines 
specified. 


ASSIGNMENT OF CONTRACT OR MORTGAGE: 


Contractor must not transfer or assign any part of or right or interest in this Contract, directly or 
indirectly, voluntary or involuntary without the express written approval of the Commissioners Court. 
Contractor must not execute any mortgage, or issue any bonds, shares of stock, or other evidence of 
interest in County buildings. 


CIVIL RIGHTS AND EQUAL OPPORTUNITY IN EMPLOYMENT: 


The Contractor agrees, during the performance of the services under this Agreement, that the Contractor 
shall provide all services and activities required in a manner that complies with the Civil Rights Act of 
1964, as amended, the Rehabilitation Act of 1973, Public Law 93-1122, Section 504, the provisions of 
the Americans with Disabilities Act of 1990, Public Law 101-336 [S.933], and all other federal and state 
laws, rules, regulations, and orders pertaining to equal opportunity in employment, as if the Contractor 
were an entity bound to comply with these laws. The Contractor shall not discriminate against any 
employee or applicant for employment based on race, religion, color, sex, national origin, age or 
handicapped condition. In accordance with Title VI of the Civil Rights Act of 1964: 


21.1 Compliance with Regulations: Contractor shall comply with the requirements relative to 
nondiscrimination in Federally-Assisted programs, including but not limited to Title VI of the 
1964 Civil Rights Act (42 USC Section 2000d, et. seq.), and 49 CFR Part 21, both as explained 
in Federal Transit Administration (FTA) Circular 4702.1A, as they may be amended (the 
“Regulations”), which are herein incorporated by reference and made a part of this Agreement. 


21.2 Nondiscrimination: Regarding the work performed by Contractor under this Agreement, it shall 
not discriminate on the grounds of race, color, or national origin in the selection and retention of 
subcontractors, including procurements of materials and leases of equipment. Seller shall not 
participate either directly or indirectly in the discrimination prohibited by section 21.5 of the 
Regulations, including employment practices. 


21:3. Solicitations for Subcontracts, Including Procurements of Materials and Equipment: In all 
solicitations either by competitive bidding or negotiation made by the Contractor for work to be 
performed under a subcontract, including procurements of materials or leases of equipment, each 
potential subcontractor or supplier shall be notified by the Contractor of the Contractor's 
obligations under this Agreement and the Regulations relative to nondiscrimination on the 
grounds of race, color, or national origin. 


21.4 Sanctions for Noncompliance: If Contractor does not comply with the nondiscrimination 
provisions of this Agreement, County shall impose the sanctions that it determines are 
appropriate, including, but not limited to, withholding of payments to Contractor under the 
Agreement until Contractor complies, or until cancellation, termination or suspension of the 
Agreement, in whole or in part. 


21.5 


21.6 


The Contractor further agrees that the County or its duly authorized representatives shall have 
access to any and all books, documents, papers, reports and records of the Contractor, which the 
County deems are directly pertinent to the services to be performed under this Agreement for the 
purposes of making audits, examinations, excerpts, and transcriptions, and to ascertain 
compliance with federal and state employment discrimination laws. Contractor shall provide all 
information and reports required by Title VI of the 1964 Civil Rights Act (42 USC Section 
2000d, et. seq.) and any regulations or directives issued pursuant to them. Contractor shall permit 
access to its books, records, accounts, other sources of information and its facilities as County 
may determine to be pertinent to ascertain compliance with these regulations, orders, and 
instructions. Where any information required of Contractor is in the exclusive possession of 
another who fails or refuses to furnish this information, Contractor shall so certify to the County, 
as appropriate, and shall state what efforts it has made to obtain the information. 


Incorporation of Provisions: Contractor shall include the provisions of sections 21.0 - 21.6 
(regarding nondiscrimination) in every subcontract, including procurements of materials and 
leases of equipment, unless exempt by the Regulations, or directives issued pursuant to them. 


22.0 GRATUITIES: 


County may terminate this Contract if it is found that gratuities of any kind including entertainment, or 
gifts were offered or given by the Contractor or any agent or representative of the Contractor, to any 
County Official or employee with a view toward securing favorable treatment with respect of this 
Contract. If this Contract is terminated by the County pursuant to this provision, County shall be 
entitled, in addition to any other rights and remedies, to recover from the Contractor at least three times 
the cost incurred by Contractor in providing the gratuities. 


23.0 FORFEITURE OF CONTRACT: 


23.1 


Contractor must forfeit all benefits of the Contract and County must retain all performance by 
Contractor and recover all consideration or the value of all consideration, paid to Contractor 
pursuant to this contract if: 


23.1.1 Contractor was doing business at the time of submitting its proposal or had done business 
during the 365 day period immediately prior to the date of which its proposal was due 
with one or more Key Contracting Persons if Contractor has not disclosed the name of 
any such Key Contracting Person in its proposal which is expressly incorporated in this 
Contract; or 


23.1.2 Contractor does business with a Key Contracting Person after the date on which the 
proposal that resulted in this Contract and prior to full performance of the Contract and 
fails to disclose the name of that Key Contracting Person in writing to each member of 
the Commissioners Court and to the County Clerk within ten (10) days commencing 
business with that Key Contracting Person. 


24.0 NOTICES: 


24.1 


Any notice required or permitted to be given under this Contract by one party to the other shall 
be in writing and shall be given and deemed to have been given immediately if delivered in 
person to the address set forth in this section for the party to whom the notice is given, or on the 
third day following mailing if placed in the United States Mail, postage prepaid, by registered or 
certified mail with return receipt requested, addressed to the party at the address set forth in this 
Section. 
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24.2 


24.3 


24.4 


The address of County for all purposes under this contract shall be: 


Cyd Grimes, C.P.M., CPPO 
Purchasing Agent 

P.O. Box 1748 

Austin, Texas 78767-1748 


The address of the Contractor for all purposes under this contract and for all notices hereunder 
shall be the address shown in the Notice of Award. 


Each party may change the address for notice to it by giving notice of the change in compliance 
with 24.0. 


CONSTRUCTION OF CONTRACT: 


25.1 


25.2 


25.3 


25.4 


25.5 


Law and Venue. This Contract is governed by the laws of the United States of America and 
Texas and all obligations under this contract are performable in Travis County, Texas. Venue for 
any dispute arising out of this Contract will lie in the appropriate court of Travis County, Texas. 


Severability. If any portion or portions of this Contract are ruled invalid, illegal, or unenforceable 
in any respect, by a court of competent jurisdiction, the remainder of it shall remain valid and 
binding. 


Headings. Headings and titles at the beginning of the various provisions of this Contract have 
been included only to make it easier to locate the subject matter covered by that part, section or 
subsection and are not to be used in construing this Contract. 


Computation of Time. When any period of time is stated in this Contract, the time shall be 
computed to exclude the first day and include the last day of period. If the last day of any period 
falls on a Saturday, Sunday, or a day that Travis County has declared a holiday for its employees, 
these days shall be omitted from the computation. All hours stated in this Contract are stated in 
Central Standard Time from 2:00 o'clock a.m. on the first Sunday October until 2:00 o'clock a.m. 
on the first Sunday of April and in Central Daylight Saving Time from 2:00 o' clock a.m. on the 
first Sunday April until 2:00 o'clock a.m. on the first Sunday of October. 


Gender and Number: Words of any gender in this Contract shall be construed to include any 
other gender and words in either number shall be construed to include the other unless the 
context in the Contract clearly requires otherwise. 


ENTIRE CONTRACT: 


All oral and written agreements between Contractor and County relating to the subject matter of this 
Contract that were made prior to the execution of this Contract have been reduced to writing and are 
contained in this Contract. 


CONTRACTOR LIABILITY, INDEMNIFICATION AND CLAIMS NOTIFICATION: 


27.1 


Contractor shall indemnify County, its officers, agents, and employees, from and against any and 
all third party claims, losses, damages, causes of action, suits, and liability of every kind whether 


27.2 


meritorious or not and, including all expenses of litigation, court costs, and reasonable attorney's 
fees, arising in connection with the services provided by Contractor under this Contract. It is the 
expressed intention of the parties to this contract, both Contractor and County, that the indemnity 
provided for in this paragraph is indemnity by Contractor to indemnify and protect County from 
the consequences of Contractor's actions. 


Contractor warrants that all applicable copyrights, patents, and licenses which may exist on 
materials used in this Contract have been adhered to and further warrants that County shall not 
be liable for any infringement of those rights and any rights granted to County shall apply for the 
duration of the Contract. CONTRACTOR SHALL INDEMNIFY COUNTY, ITS OFFICERS, 
AGENTS AND EMPLOYEES FROM ALL CLAIMS, LOSSES, DAMAGES, CAUSES OF 
ACTION AND LIABILITY OF EVERY KIND, INCLUDING EXPENSES OF LITIGATION, 
AND COURT COSTS AND ATTORNEY FEES FOR DAMAGES TO ANY PERSON OR 
PROPERTY ARISING IN CONNECTION WITH ANY ALLEGED OR ACTUAL 
INFRINGEMENT OF EXISTING LICENSES, PATENTS, OR COPYRIGHTS APPLICABLE 
TO MATERIALS USED IN THIS CONTRACT. This section shall not be interpreted as a 
waiver of sovereign immunity and County retains all of its affirmative defenses. 


28.0 HUB PROCUREMENT PROGRAM: 


28.1 


28.2 


28.3 


28.4 


28.5 


Pursuant to the Travis County Historically Underutilized Business (HUB) Procurement Program, 
the Travis County Commissioners Court adopted goals for Certified HUB Subcontractor 
participation with an Overall 14.1% Minority-Owned Business Enterprise (MBE) goal and an 
Overall 15.0% Women-Owned Business Enterprise (WBE) goal (Sub-goals: 2.5% African- 
American, 9.9% Hispanic, 1.7% Native/Asian-American) to be observed by the County in its 
award of contracts and subcontracts to certified HUBs. 


It is the policy of Travis County that HUBs shall have the maximum opportunity to participate in 
the performance of county contracts and subcontracts. Contractors shall make a "good faith 
effort” to take all necessary and reasonable steps to ensure HUBs maximum opportunity to 
participate as subcontractors. Failure by a contractor or subcontractor to carry out the County 
HUB Procurement Program shall constitute a breach of contract, and after notification of such 
breach by the Purchasing Agent may result in termination of this contract. 

For purposes of HUB participation, Travis County shall count the dollar amount of all firm fixed 
price/fixed quantity contracts, or the dollar amount of Purchase Orders placed against 
"Estimated" or "Not to Exceed" contracts. 


The following section identifies the specific procedures to be followed with respect to this 
solicitation for proposals in compliance with the HUB Procurement Program. 


SECTION 1 - HUB PURCHASES 
28.5.1 To be eligible under this program, HUB Proposers and subcontractors must: 
28.5.1.1 Be certified as HUB, M/WBE or DBE source by: 
(A)City of Austin Municipal Government, 
(B)Texas Unified Certification Program, or 


(C)State of Texas Building and Procurement Commission 


28.5.2 


28.5.1.2 Have on file in the Travis County Purchasing Office a proper Bidder’s 
Application. 


28.5.1.3 Identify the certifying agency and Item/Service for which is certified. 


28.5.1.4 Obtain county approval of all proposed HUB subcontractors through the 
Purchasing Agent. 


28.5.1.5 Complete the HUB Declaration form in this RFP package. 


Any third party may challenge a firm's HUB status before or after certification. Such 
action shall be in writing and submitted to the Purchasing Agent, including all relevant 
information available. If no merit to the challenge is found, the challenging party will be 
notified by the Purchasing Agent in writing and the matter will be considered closed. If 
merit is found, the firm in question will be notified by the Purchasing Agent of the 
challenge, who made it, and a summary of the allegations. The challenged firm shall be 
required to submit, within a reasonable period of time, information in support of the 
firm's HUB status. The Purchasing Agent shall make an evaluation and notify the parties 
of a proposed determination, citing the basis for the decision, and providing an 
opportunity for an informal hearing to interested parties and affording an opportunity for 
a written or personal response. The Purchasing Agent shall make a recommendation to 
the Commissioners Court for a final determination. The Purchasing Agent shall inform 
all interested parties of the Commissioners Court's determination and its reasons. A 
firm's HUB status shall remain accurately certified during the challenging procedure and 
shall not be changed unless or until a successful challenge is finalized. (See also Par. 8.0, 
"CLARIFICATION OR OBJECTION TO PROPOSAL REQUIREMENTS" in Part I, 
General Requirements Section of this RFP.). 


29.0 ORDER OF PRECEDENCE: 


In the event of inconsistency between provisions of this Contract, the inconsistency shall be resolved by 
giving precedence in the following ascending order: 


The Schedule of Items; 
Terms and Conditions of Request for Proposal; 


General Provisions; 

Special Provisions; 

Other provisions, whether incorporated by reference or otherwise; 
General Requirements; and 


The Specifications (Appendices A — G). 


30.0 ADDITIONAL GENERAL PROVISIONS: 


30.1 


30.2 


30.3 


County may assign any of its obligations under this Contract. 


Contractor must comply with all Federal and State laws and regulations, City and County 
ordinances, orders, and regulations, relating in any way to this Contract. 


Contractor must secure all permits and licenses, pay all charges and fees, and give all notices 
necessary for lawful operations. 


31.0 


32.0 


33.0 


34.0 


30.4 Contractor must pay all taxes and license fees imposed by the Federal and the State Governments 
and their agencies and political subdivisions upon the property and business of Contractor. 


30.5 Despite anything to the contrary in this Contract, if the Contractor is delinquent in payment of 
property taxes at the time of providing services, Contractor hereby assigns the amount of Gross 
Receipts equal to the amount Contractor is delinquent in property tax payments to the Travis 
County Tax Assessor-Collector for the payment of the delinquent taxes. 


DESIGNATED COUNTY HOLIDAYS: Travis County will not accept deliveries on days designated 
as holidays by Travis County, unless specific prior arrangements have been made. 

Travis County shall provide a list of the holidays designated for each year upon request. Travis County 
usually designates 11 days each year as holidays and below is a list of the days usually designated: 


HOLIDAY DAY(S) USUALLY CELBRATED 

New Years Dad tii January 1* or Monday after if it falls on a weekend 

Martin Luther King, Jr. Day .............. 3™ Monday in January 

President's Di dt 3" Monday in February 

Memorial Day iiisiosiosisnaiiajcióas surge 4™ Monday in May 

Independence Day ..cccoooccccoccccnonccinnnoss July 4' or Monday after if it falls on a weekend 

Labor Day aras 1* Monday in September 

Veterans Din November 11' or Monday after, if it falls on a weekend 
Thanksgiving Day ....oocooconnnncccnnnccnnonoss 4 Thursday AND Friday in November 

Christmas Season ..ocooonnnccnocncnnncconncnnnss December 25" AND either day before or day after whichever 


allows a four day weekend, if possible 
MEDIATION: 


When mediation is acceptable to both parties in resolving a dispute arising under this Agreement, the 
parties agree to use a mutually agreed upon mediator, or a person appointed by a court of competent 
jurisdiction, for mediation as described in Section 154.023 of the Texas Civil Practice and Remedies 
Code. Unless both parties are satisfied with the result of the mediation, the mediation will not constitute 
a final and binding resolution of the dispute. All communications within the scope of the mediation 
shall remain confidential as described in §154.073 of the Texas Civil Practice and Remedies Code, 
unless both parties agree, in writing, to waive the confidentiality. 


TIN REQUIRED: 


Contractor shall provide County with an Internal Revenue Form W-9, Request For Taxpayer 
Identification Number and Certification, that is completed in compliance with the Internal Revenue 
Code, its rule and regulations, and a statement of entity status in a form satisfactory to the County 
Auditor before any contract funds are payable. 


NON-WAIVER OF DEFAULT: 


34.1 The waiver of a breach of any term or condition of this Contract is not a waiver of a subsequent 
breach of that term or condition, or a breach or subsequent breach of any other term of condition. 
No official, agent, employee, or representative of County may waive any breach of any term of 


35.0 


36.0 


condition of this Contract unless expressly granted that specific authority by Commissioner 
Court. 


34.2 All rights of County under this Contract are specifically reserved and any payment, act or 
omission shall not impair or prejudice any remedy or right to County under it. Any right or 
remedy in this Contract shall not preclude the exercise of any other right or remedy under this 
Contract or under any law, nor shall any action taken in the exercise of any right or remedy be 
deemed a waiver of any other rights or remedies. 


CERTIFICATION OF ELIGIBILITY: 


This provision applies if the anticipated contract exceeds $25,000. By submitting a bid or proposal in 
response to this solicitation, the bidder/proposer certifies that at the time of submission, he/she is not on 
the Federal Government’s list of suspended, ineligible, or debarred contractors. In the event of 
placement on the list between the time of bid/proposal submission and time of award, the 
bidder/proposer will notify the Travis County Purchasing Agent. Failure to do so may result in 
terminating this Contract for default. 


INSURANCE: 


Contractor shall have, Standard Insurance sufficient to cover the needs of Contractor and/or 
Subcontractor pursuant to applicable generally accepted business standards. Depending on services 
provided by Contractor and/or Subcontractor, Supplemental Insurance Requirements or alternate 
insurance options as set forth in Attachment 10, "Insurance Requirements," may be imposed. 


CONTRACTOR: 


By: 
Printed Name: 
Its Duly Authorized Agent 


Date: 


TRAVIS COUNTY: 


By: 
Sarah Eckhardt 
Travis County Judge 


Date: 


APPROVED AS TO FORM: 


County Attorney 


AVAILABILITY OF FUNDS CONFIRMED: 


Nicki Riley, Travis County Auditor 


Date: 


APPROVED AS TO PURCHASING POLICIES AND PROCEDURES: 


Cyd V. Grimes, C.P.M., CPPO 
Travis County Purchasing Agent 


Date: 


1.0 


TERMINOLOGY 


ATTACHMENT 1 
TERMINOLOGY 


1.1 TERMS AND ACRONYMS 


The term “Administrator” refers to a county election official responsible for conducting 


elections and implementing and using STAR-Vote™. 


Any requirements and specifications indicated by the word “must” or “shall,” will be fully 
implemented by any successful proposal. Those constraints or limitations indicated by “must 
not,” or “may not” will not be included in a successful proposal. Those requirements and 
specifications indicated by “should,” “preferred,” or “ideally” represent preferred elements or 
guidelines for how the designers of this specification envision its realization, but are intended 


to leave flexibility in its ultimate form. 


A Glossary is provided at the end of this document to assist in clarifying terms used in this 


RFP. 


Frequently used acronyms include: 


Acc-VS Accessible Voting Station 

BCS Ballot Control Station 

BBM Ballot-By-Mail 

CSS Cascading Sheet Style 

COTS Commercial Off-the-Shelf 

ED Election Day 

EDF Election Definition File 

EML Election Markup Language 

ENR Election Night Return Internet System 
EVBB Early Voting Ballot Board 

EV Early Voting 

EVR Electronic Vote Record 

FBR Failed Beyond Repair 

FPCA Federal Post Card Application 
JSON JavaScript Object Notation 
L&A Logic and Accuracy Testing 
MID Machine Identifier 

NIZK Non-Interactive Zero-Knowledge 
PCID Page Casting Identifier 

PID Page Identifier 

PVR Printed Vote Record 

RAND Reasonable and Non-Discriminatory 
SOR Statement of Residency 

SOS Texas Secretary of State 

TEC Texas Election Code 


UOCAVA Uniformed and Overseas Citizens Absentee Voting Act 
UUID Universally Unique Identifier 

VR Voter Registration 

VEBD Voter Editable Ballot Device 

VEBD-A Voter Editable Ballot Device (Audio) 

VVSG Voluntary Voting System Guidelines 

XML Extensible Markup Language 


12 GLOSSARY 


12.1 


132.2 


1.2.3 


1.2.4 


1.2.5 


1.2.6 


AIR-GAPPED SYSTEM (AGS): Encompasses all elements of STAR-Vote™ 
that are used in polling locations or for tabulation, and any systems that at any 
point have a network connection to other AGS devices. These systems are 
considered “Air-gapped” as they should never have a direct physical connection 
to any system outside of the AGS. Due to their sensitive nature, electronic 
information flow into the system is carefully controlled. 


AUDIT HASH CHAIN SEED: A value used as the “previous element’s hash’ 
when calculating the first element’s hash in a hash chain. See Hash Chain. 


AUDIT LOG: A subset of the Message Log containing sufficient information to 
generate encrypted tallies, verify hash chains involving ballot data (including the 
generation of Launch Codes) and verify that there were no anomalies during the 
election process. Ballot Definition File 


CASCADING STYLE SHEET (CSS): Cascading Style Sheets (CSS) is a style 
sheet language used for describing the look and formatting of a document written 
in a markup language. While most often used to style web pages and interfaces 
written in HTML and XHTML, the language can be applied to any type of 
XML/JSON/Human Readable document, including plain XML/JSON, SVG and 
XUL. CSS is a cornerstone specification of the web and almost all web pages use 
CSS style sheets to describe their presentation. See 
http://en.wikipedia.org/wiki/Cascading_Style_Sheets. 


COMMITMENT-CONSISTENT ENCRYPTION: An encryption algorithm 
that is commitment-consistent and enables the Entity that can decrypt the data 
(the private key holder) to prove to a third party that what it claims is a valid 
decryption of a given ciphertext is actually the decryption of that ciphertext 
without enabling the third party to decrypt any data itself. 


COMPONENTIZED SOFTWARE ELEMENT: A software component 
designed to implement an externally-defined interface such that the component 
may be “swapped” with a comparable software component without modification 
of any code in any other element of the software. 


1.2.7 


1.2.8 


1.2.9 


1.2.10 


1.2.11 


1.2.12 
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1.2.14 


CRYPTOGRAPHIC MIXNET: Cryptographic mixnets (short for “mix 
networks”) are routing protocols that seek to prevent any one person or Entity 
from knowing which encrypted output corresponds to which encrypted input. 
This is accomplished by using a chain of servers each of which re-encrypts and 
randomizes the order of the data. A mixnet is considered verifiable if it is able to 
prove (or provide significant evidence) that there is a 1-to-1 correspondence 
between its inputs and its outputs without revealing the correspondence. 


CRYPTOGRAPHICALLY RANDOM: A random value (typically a number) 
that is generated in such a way as to make it highly mathematically improbable 
that knowing any arbitrarily long sequence of prior random numbers would allow 
someone to predict the next random value. Strictly speaking, cryptographically 
random numbers are generated such that they have high entropy. 


DEVICE ROLE: The prescribed role a given device has been authorized to fill 
during an Election while connected to a Polling Location Network. Current 
expected Device Roles are: Voting Station, Ballot Control Station, Ballot 
Scanner, Device Initialization, Tabulator, Trustee. 


DIGITAL CERTIFICATE: An electronic document used to verify the identity 
of the entity in possession of a private key associated with a public key named in 
the Digital Certificate. Digital Certificates are created by the entity whose 
identity is to be verified, and are then digitally signed by a trusted Certification 
Authority, which is implicitly attesting that it has verified the identity of the 
certificate provider prior to signing. 


ELECTION CERTIFICATION AUTHORITY: A Digital Certificate which is 
entrusted with the sole authority to sign Digital Certificates from election devices, 
stating that those devices are permitted to participate in the election for which that 
Election Certification Authority was created. 


ELECTION DEFINITION: A digitally signed file (or collection of files) which 
contains the complete set of electronic data required by STAR-Vote™ to run an 
election. This includes (but is not limited to) ballot styles, the Election Public 
Key, and the Election Certification Authority public certificate. 


ELECTION PUBLIC KEY: Public key used to encrypt all votes, and any data 
which must be recoverable by an audit or later investigation during the election. 
Data encrypted with this key can be decrypted only when a threshold number of 
Election Trustees coordinate to decrypt it. 


ELECTRONIC VOTE RECORD (EVR): An electronic record containing one 
voter’s encrypted selections, as well as proofs about good structuring of the data 
and various metadata required by STAR-Vote™. 


1.2.15 


1.2.16 


1.2.17 


1.2.18 


1.2.19 


1.2.20 


1.2.21 


END-TO-END ENCRYPTION (E2E): An encryption system that allows for 
any manipulations of the data required during normal operations to happen 
without first decrypting the data. In the context of a voting system, an end-to-end 
encryption system enables tallying and verification of the tally without ever 
decrypting individual ballots. 


EXTENSIBLE MARKUP LANGUAGE (XML): A markup language that 
defines a set of rules for encoding documents in a format that is both human- 
readable and machine-readable. It is defined in the XML 1.0 Specification 
produced by the World Wide Web Consortium (W3C), and several other related 
specifications, all free open standards. 


FEDERAL POSTCARD APPLICATION (FPCA): A ballot by-mail 
application for U.S. citizens residing outside the United States, and for U.S. 
citizens who are active members of the Uniformed Services, the Merchant 
Marines, the commissioned corps of the Public Health Service and National 
Oceanic and Atmospheric Administration, and their eligible family members. 
This application registers the applicant to vote (if not already registered) and 
allows the applicant to receive a ballot-by-mail. 


GOOD ORDERING: Good ordering implies the order in which items are 
created / sent / intended to be received is the order in which those items are 
received and (if applicable) stored. 


HARDWARE SECURITY MODULE (HSM): A specialized device used to 
securely generate and store cryptographic keys, and to encrypt, decrypt, and/or 
digitally sign data with these keys. HSMs generally include tamper-resistant 
features which significantly impede any attempts at raw key extraction but offer 
capabilities to back-up keys to other HSMs. 


HASH CHAIN: A hash chain is a technique for providing tamper-evidence to 
sequential data. For each element in the chain, a cryptographic hash is calculated 
of the data in that element combined with the hash of the previous element. If at 
any point in the chain data is altered, inserted, or deleted, none of the hashes from 
that point on would match, thus providing evidence that the data has been 
tampered with. This can be further strengthened by creating independent records 
of the elements’ hashes as STAR-Vote™ accomplishes with its Paper Receipt. 


HOMOMORPHIC ENCRYPTION ALGORITHM: Generally, an additively 
Homomorphic encryption algorithm is an encryption algorithm that allows a user 
to take two encrypted numbers and combine them into an encryption of the sum 
of the two numbers. 
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1.2.26 


1.2.27 


1.2.28 
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1.2.30 


1.2.31 


LAUNCH CODE: A code that is inserted into the audit hash chain at the 
beginning of each Election Day, and that is not capable of being known in 
advance. 


MESSAGE LOG: A complete log of every network message received or sent by 
a device while connected to a polling location network. 


MACHINE IDENTIFIER (MID): Assigned number that uniquely identifies a 
specific machine in an election. 


NON-INTERACTIVE ZERO-KNOWLEDGE (NIZK) PROOF: (From 
Wikipedia): In cryptography, a zero-knowledge proof or zero-knowledge protocol 
is a method by which one party (the prover) can prove to another party (the 
verifier) that a given statement is true, without conveying any additional 
information apart from the fact that the statement is indeed true. A non-interactive 
zero-knowledge proof is a variant of the zero-knowledge proof in which no 
interaction is necessary between prover and verifier. 


In the context of STAR-Vote™, NIZK proofs consist of a small number of 
calculated values that cannot be calculated if a value is not able to be decrypted, 
and that enable the verifier to prove that the value in an encryption matches what 
the STAR-Vote™ operator claims it matches. For specific examples, see 
Attachment 8. 


NONCE: A cryptographically random number that is inserted into a process or 
structure to add an additional layer of security. 


NON-VOLATILE MEMORY: Any data storage element that retains its data 
when the device loses power. Examples include Hard Disk Drives, USB thumb 
drives, flash memory, DVDs, etc. 


PAGE CASTING IDENTIFIER (PCID): Number (possibly sequential) that is 
assigned to a specific page of a specific Printed Vote Record (PVR) and is 
guaranteed to be unique within the polling location in which the PVR is produced. 
Used for inventory tracking within the polling location, and identifying PVR 
Pages during the Risk Limiting Audit. 


PAGE IDENTIFIER (PID): Cryptographically random number uniquely 
identifying a specific page of a specific Printed Vote Record (PVR) and that is not 
stored in plaintext at any point during the election except physically on the sheet 
of paper to which it refers. 


PRINTED VOTE RECORD (PVR): The physical printed paper record of a 
voter’s selections that he or she reviews and places into a ballot box to cast a vote. 


PUBLIC ELECTRONIC VOTE RECORD (PEVR): An excerpt of an 
Electronic Vote Record (EVR) that contains sufficient information to verify the 


1.2.32 


1.2.33 


1.2.34 


1.2.35 


1.2.36 


1.2.37 


1.2.38 


1.2.39 


election tallies but minimizes the amount of information that would be disclosed 
in the event that the encryption technologies used are broken. 


PUBLIC KEY: In asymmetric key cryptography, a Public Key is one-half of a 
public-private key pair. Values encrypted using the public encryption key can be 
decrypted by someone with the private key. In such a scheme, an entity 
publishes, or “makes public” the Public Key, and then can enable secure 
communication from others to the entity (via encryption with the Public Key). A 
public signature verification key enables public verification of digital signatures 
created using a corresponding private signature key. 


SINGLE RACE SELECTION VECTOR (SRSV): A SRSV is the basic unit of 
storage for a voter’s selections for a single race. 


SYSTEM IMAGE: A data element that includes the entire operating system, 
application, drivers, election-specific information, security components and any 
other data required for a specific device to perform its function within the STAR- 
Vote™ system for an election. 


THRESHOLD ENCRYPTION: A threshold encryption system is one in which 
a group of private keyholders coordinate to perform decryption. Each participant 
creates its own public / private key pair. A threshold, k, is chosen, and a threshold 
public key calculated such that no data encrypted with that key can be decrypted 
unless at least k keyholders participate. So long as k is less than the total number 
of keyholders, n, then the system is robust to n — k keys being lost without losing 
the ability to decrypt data. 


TRANSPORT LAYER SECURITY (TLS): Industry-standard technology for 
providing secure point-to-point communication over a public network (such as the 
internet). TLS is an Internet Engineering Task Force standard. 


TRUSTED PLATFORM MODULE (TPM): An international standard for a 
secure cryptoprocessor that is a dedicated microprocessor designed to secure 
hardware by integrating cryptographic keys into devices. TPMs offer facilities for 
the secure generation and storage of cryptographic keys, in addition to random 
number generation. 


TUPLE: An ordered set of items of potentially different types. Typically written 
comma-delimited between parentheses (e.g. “(1, ‘frog’, OxA2B4C6D8)”). 
Contrast with a vector. 


UNIFORMED AND OVERSEAS CITIZENS ABSENTEE VOTING ACT 
(UOCAVA): Provides the legal basis for absentee voting requirements for federal 
offices to U.S. citizens residing outside the United States, and to U.S. citizens 
who are active members of the Uniformed Services, the Merchant Marines, the 


commissioned corps of the Public Health Service and National Oceanic and 
Atmospheric Administration, and their eligible family members. 


1.2.40 UNIVERSALLY UNIQUE IDENTIFIER (UUID): A UUID is a 16-octet (128- 
bit) number. In its canonical form, a UUID is represented by 32 lowercase 
hexadecimal digits, displayed in five groups separated by hyphens, in the form 8- 
4-4-4-12. Proper UUID generation ensures that the probability of two 
independently generated UUIDs having the same value is exceptionally small. 


1.2.41 USER INTERFACE (UI): Any piece of a software or hardware system with 
which any person is expected to interact once the system is deployed. 


1.2.42 VECTOR: An ordered set of items, all of the same type. Typically written 
comma delimited between angle brackets (e.g. “<1, 4, 3, 7>”). Technically, a 
special case of a tuple. 


1.2.43 VOLATILE MEMORY: Any data storage element that does not retain its data 
when the device loses power. The most common example is a computer’s RAM 
memory, or various internal caches. 


1.2.44 VOTER EDITABLE BALLOT DEVICE — AUDIO (VEBD-A): Used within 
the VVSG to refer to recommendations around the presentation and interaction of 
a voting system when an audio interface is used by a voter. 


1.2.45 VOTER EDITABLE BALLOT DEVICE — VISUAL (VEBD-V): Used within 
the VVSG to refer to recommendations around the presentation and interaction of 
a voting system when a visual interface is used by a voter. 


1.2.46 WELL-FORMED: Conforming to all rules of the relevant language, schema, or 
specification. In this context, the term should be interpreted with two more subtle 
meanings: (1) With regard to encrypted ballots, it requires that votes encrypted 
within those ballots are valid — i.e. that each vote counter contains a number 
which is non-negative and no larger than the maximum number of votes that a 
voter may cast for that candidate (typically 1), and that the ballot does not contain 
more votes in any race than are permitted for that race. (2) With regard to data 
structures generally, it requires that data that is intended to conform to a standard 
can be correctly read by any software that correctly implements that standard. 


1.2.47 XML: See Extensible Markup Language. 


ATTACHMENT 2 
VVSG Gap Analysis 


Due to the size of the VVSG Gap Analysis, this document will be made available upon request 
only. Please send your request via email to lori.clydeOtraviscountytx.gov. 


ATTACHMENT 3 
Texas Election Code Gap Analysis 


Due to the size of the Texas Election Code Gap Analysis, this document will be made available 
upon request only. Please send your request via email to lori.clyde@traviscountytx.gov. 


ATTACHMENT 4 
Ballot Style Tokens 


Primary Ballot Style Token 


Primary Provisional Ballot Style Token 


Regular Ballot Style Token 


1130976557 X, MISTER 
498 UNNAMED ST. 
AUSTIN 213A 


REPUBLICAN 
CC TTL LL 


R213A pum 
REPUBLICAN 


1130976557 
X, MISTER 


P1130976557 X, MISTER 
498 UNNAMED ST. 
AUSTIN 213A 


PD213A anim 
DEMOCRAT 


DEMOCRAT 
DOBDIEDDDDE TA DORA IDO TERETE 


P1130976557 
X, MISTER 


1130976561 X, MADAME 
498 UNNAMED ST. 
AUSTIN 213A 


213A pmm 


1130976561 
X, MADAME 


Attachment 5 
SAMPLE PVR 


Official Ballot November 4, 2012 


Joint General and Special Elections 
Travis County, Texas Precinct 101A 


Travis County General Election 


Straight Party 
PURP Purple 
District 210, United States Representative 
PURP Anna Alpha 
Governor 
PURP Betty Beta 
Lieutenant Governor 
PURP Gertrude Gamma 
Attorney General 
PURP Daniel Delta 
State Senator 
PURP Eric Epsilon 
Comptroller of Public Accounts 
GLD Zitta Zeta 
Attorney General 
PURP Derick Delta 
State Senator 
PURP Edith Epsilon 
Comptroller of Public Accounts 
GLD Zorro Zeta 
Commissioner of the General Land Office 
PURP Etta Eta 
Commissioner of Agriculture 
PURP Theodore Theta 
Railroad Commissioner 
PURP Onne lota 
District 257, State Senator 
NO SELECTION 
Place 456, Justice, 33rd Court of Appeals District 
PURP Larry Lambda 
Place 334, Justice, Supreme Court 
NO SELECTION 
Place 667, Judge, Court of Criminal Appeals 
NO SELECTION 
District 589, Member State Board of Education 
PURP Karla Kappa 
District 257, State Senator 
NO SELECTION 
Place 456, Justice, 33rd Court of Appeals District 
PURP Leticia Lambda 


Soeooseododsessgess SF Fsgsgs 8s 8 O 


OOOO CRA BEA 
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Travis County General Election continued 


Precinct 145, Justice of the Peace 

PURP Nancy Nu @ 
District 147, State Representative 

PURP Xenaxi @ 
County Judge 

PURP Oscar Omicron @ 
County Court at Law 677, Judge 

PURP Peggy Pi @ 
County Probate Court Judge 

PURP RhodaRho @ 
District Clerk 

PURP Samuel Sigma @ 
County Clerk 

GLD Teresa Tau @ 
County Treasurer 

PURP Uma Upsilon Q 
District Clerk 

PURP Selena Sigma @ 
County Clerk 

GLD Thomas Tau @ 
County Treasurer 

PURP Ulysses Upsilon @ 
County Commissioner 

PURP Phillip Phi @ 
Railroad Commissioner 

PURP Charles chi @ 
Place 332, Justice, Supreme Court 

NO SELECTION O 


Central Health Tax Ratification Election 
Propositon 1 


For @ 

Propositon 2 
Against D 

Propositon 3 
For @ 


Austin Community College Board of Trustees 
Election 
Place 7, ACC Trustee 

Umberto Upsigma (2) 


RR O 
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Attachment 6 
SAMPLE VOTER RECEIPT 


Thank you for voting! 


Take this confirmation of voting with you 
Verify your ballot at: 
www.star-vote.org/ballot/ 


HV1235Z7568RK84 


Enter this unique code: 


Find your code on the STAR-Vote website to ensure that your vote was recorded correctly. 


Look for Election results and other tools for confirming the election at: 
www.traviscountyelections.org 


Voting Date: October 30, 2012 Location: Randall's South Mopac 
Voting Terminal: Ul12345 Time: 18:45:56 


Attachment 7 
COMPREHENSIVE SAMPLE BALLOTS 


Comprehensive Ballot — County General and Constitutional Amendment Elections 


Travis County Clerk Elections Division 
November 4, 2014 Joint General and Special Elections 


Division de Elecciones de la Secretaria del Condado de Travis 


el 4 de noviembre de 2014 Elecciones Generales y Especiales Conjuntas 
If you do not know your election precinct or need other election information, call the 
Travis County Clerk Elections Division at (512) 238-VOTE (8683). www traviscountyelections.org 
Si usted no sabe su precinto de elección o para más información sobre la elección, llame a la División de Elecciones 
de la Oficina de la Secretaria del Condado de Travis (512) 238-VOTE (8683). www.traviscountyelections.org 


raight Part 
(Partido Completo) 


All precincts / Precintos enteros 


L Republican / Republicano 
O Democratic / Democrático 
O Libertarian / Libertariano 
© Green / Verde 


United States Senator 
¡Senador de los Estados 
inidos) 


AB precincts / Precimios enteros 


John Cornyn - REP 
David M. Alamee! - DEM 
Rebecca Paddock - LIB 
Emily “Spicybrown” 
Sanchez - GRN 
Write-in / Voto Escrito 


District 10, United States 
ive 


(Distrito Núm. 10, Representante 
de los Estados Unidos) 


Precincts / Precintos. 103. 104, 105, 106. 108. 
114, 196, 123, 125. 127. 131, 136, 134, 140, 
141, 142, 146, 149, 150, 193, 154, 156, 200, 
203,211. 212. 217, 218, 222, 227.728 235, 
236, 237, 239. 240, 241, 242, 243, 245, 248, 
268. 
335, 


coogJ 


248, 240, 252. 253, 258, 200, 262, 204. 
273, 321, 323, 326, 327, 331, 333, 334, 
396, 337, 443, 374, 375 


LL Michael McCaul - REP 
O Tawana Walter-Cadien - DEM 
O Bill Kelsey - LIB 


District O Es 
(Distrito Núm, 17, Representante 
de los Estados Unidos) 


Precincts / recintos: 102. 107, 109, 110, 111 
112, 113, 137, 145, 148, 160, 161, 163, 205, 
207.715, 216. 210, 225, 228, 729, 254, 259, 
26), 267. 305, 328, 45 


D Bill Flores - REP 
M Nick Haynes - DEM 


O Shawn Michael Hamilton - LIB 


District 21, United States 
ive 


Patri Núm. 21, Representante 
de los Estados Unidos) 


Precincts / Precistos 250, 277, 301, 309, 310. 
311. 314, 315, 329, 330, 332, 339, 340. 341 
342, 344, 349, 350, 351, 352, 354, 354 357, 
363, 265, 368. 406, 408, 409 412. 416 418, 
410, 420, 421, 422, 424, 428, 430, 431. 433, 
435, 437, 448. 454, 458. 400. 481 


L Lamar Smith - REP 
M Ryan Shields - LIB 
D Antonio Diaz - GRN 


District 25, United States 


(Dibine Nom 2: 
Ú Núm. 25, Representante 
de los Estados Unidos) 


Precincts / Precios. 122, 124. 
132, 133, 135. 151, 152. 202, 206, 208, 210, 
213, 214, 220, 221, 231, 232, 233. 234, 238. 
244, 247. 251, 256, 274, 275, 302, 303, 304, 
306, 307. 306, 342, 313,316, 317, 318, 319, 
320, 324, 325. 338, 346. 347. 358. 359, 360. 
‘381, 362, 164, 366, 367, 369, 370, 371, 372, 
373,492.44 


126, 129. 130. 


© Roger Williams - REP 
© Marco Montoya - DEM 
L John Betz - LIB 


District 35, United States 


(Olano Nom 3 

a Núm. 35, Representante 
de los Estados Unidos) 
Precincts / Precintos 101, 115. 116, 117, 119, 
120. 121. 128, 134, 139, 164, 209. 223, 224. 
401, 402, 403, 404, 405, 407, 410 411, 412, 
414. 419, 417, 423, 425, 420, 427, 429, 416. 
436 439 440, 441 447 443, 444 447, 448, 
450, 451, 452, 463 


Susan Narvaiz- REP 
Lloyd Doggett - DEM 
Cory W. Bruner - LIB 
kat swift - GRN 


acon 


vernor 
(Gobernador Teniente) 
All precincts / Precntos enteros. 


L Dan Patrick - REP 
C Leticia Van de Putte - DEM 
E Robert D. Butler - LIB 
L- Chandrakantha Courtney - GRN 
Attorney General 
(Procurador General) 
Al preancts / Precntos enteros 


F Ken Paxton - REP 
Sam Houston - DEM 
C Jamie Balagía - LIB 
FT Jamar Osborne - GRN 


Comptroller of Public 
Accounts 

(Contralor de Cuentas 
Públicas) 

All preancts / Precintas enteros 


C Glenn Hegar - REP 
M Mike Collier - DEM 
E Bon Sandors - LIB 
C Dob Shafto - GRN 


Commissioner of the General 


= 
L Justin Knight - LIB 
C 


U 
© Jim Hogan - DEM 

E David (Rocky) Palmquist - LIB 
© Kenneth Kendrick - GRN 


Railroad Commissioner 


aci e 


A! precincts / Precintos enteros 


O Ryan Sitton - REP 
m Steve Brown - DEM 
UY Mark A. Miller - LIB 
O Martina Salinas - GRN 


Chief Justice, Supreme 
Court 
(Juez Presidente, Corte 


Suprema) 
A preoncts / Precntos enteros 


O Nathan Hecht - REP 
1 William Moody - DEM 
3 Tom Oxford - LIB 
Place 6, Justice, Supreme 
Court, Unexpired Term 
(Lugar ce 6, eres Corte 
Suprema, Dur: 


ación Restante 
del Cargo) 
AN precncts / Precintos enteros. 


U Jeff Brown - REP 
M) Lawrence Edward Meyers - DEM 
J Mark Ash - LIB 


Place 7, Justice, Supreme 
{Li Núm. 7, Juez, Corte 
ugar Núm. 7, Juez, 
Suprema) 


Ai preancts / Precuntos enteros 


m Jeff Boyd - REP 

© Gina Benavides - DEM 
© Don Fulton - LIB 

U Charles E Waterbury - GRN 


Place 8, Justice, Supreme 
(Li Núm. 8, Juez, Corte 
ugar Núm. 8, 3 
Suprema) 


A) preoncts / Precintos enteros 


) Phil Johnson - REP 
7 RS Roberto Koelsch - LIB 
m Jim Chisolm - GRN 


Place 3, y SOME Of 


Criminal 
(Lugar Núm. 3, AE Corte de 
Apelaciones Criminales) 


AI precncta / Precintos enteros. 


O Bert Richardson - REP 
O John Granberg - DEM 
O Mark W Bennett - LIB 


Place 4, Judge, Court of 
Criminal Appeals 
(Lugar Núm, 4, Juez, Corte de 
Apelaciones Criminales) 
Wi precincts / Precintos enteros 

| Kevin Patrick Yeary - REP 


M Quanah Parker - LIB 
O Judith Sanders-Castro - GRN 


Place 9, Judge, Court of 
Criminal 

(Lugar Núm. 9, Juez, Corte de 
Apelaciones Criminales) 


AS precincts / Precintos enteros 


O David Newell - REP 
O Wiliam Bryan Strange, 111 - LIB 
LJ George Joseph Aligot - GRN 


District 14, State Senator 
Core Núm. 14, Senador 


Precincts / Precimtos: 101, 102. 103, 104, 105. 
106, 107, 108. 109, 110, 111, 112, 119, 114, 


pas 


234, 235. 


BEB 


BEY 
suey 
=NOeN 


z 
RE 
$ 
8 
PEET FEET 


EEEE E E 
BEGNSSEE 
z: 


EGRSRERSSERES: 
gg 


£2 


a8 
ers 
#3 


3 

EH 
Sees 

2388 


$8; 
3 


ESNSESRUSEZES 
55 


IEEE 
gessgse 


PRE 
$ 


i 


intos 302, 303. 304, 310, 315, 
WBS. 366, 367, 406, 408, 411, 414. 


| Donna Campbell - REP 
A Daniel Boone - DEM 
O Brandin P Lea - LIB 


Precincts / Precintos: 105, 113, 118, 117, 118, 
120, 121. 122. 124, 125, 120. 127, 129 130, 
131, 132, 133, 134, 135, 136, 139, 141, 142, 
145, 146, 148, 151, 152. 155. 160, 203. 217, 
223, 724, 436 444 


m Dawnna Dukes - DEM 
O Kevin Ludiow - LIB 


4 Precintos 232, 733. 234. 244, 245, 
4.345, 


Nn 

ma 
pb ae 
4, 375, 401 


. Workman - REP 
McKinlay - LIB 


an. 412 413, 414 
447, 451,458 463 


Precincts / Precintos: 149, 200, 202, 206, 208, 


209, 214, 218, 222. 228, 235, 230, 239, 240. 


288, 273. 274, 275, 277. 305, 311, 313, 323. 
325, 329, 332 340, 342. 345, 409, 425, 430. 
446, 454, 480, 461 


3 Elliott Naishtat - DEM 
3 Daniel Krawisz - LIB 


District 60, State 
iv 

(SEE NS, Recent 

Estatal) 


Precincts / Precintos: 102, 103, 104, 106, 107, 


108, 109, 110, 111, 112, 123, 128, 197, 140, 
150, 153, 154, 161, 163, 164, 205, 207. 211, 
215,216. 219, 225, 220, 227, 220, 254. 259. 
263, 321, 326, 327. 328, 331, 335 


3 Miko VanDoWalle - REP 
3 Celia Israel - DEM 
2 David Dreesen - LIB 


Precincts / Precintos: 101, 114, 115, 119, 138, 
344, 401, 402, 403, 404, 405, 407, 410. 420, 
421, 422, 423, 424, 420, 427. 426, 429, 431 
432, 433, 434, 437. 438, 439, 440, 441, 442 
443, 448, 450. 452 


J) Eddie Rodriguez - DEM 
| Arthur DiBlanca - LIB 


Chief Justice, 3rd Court of 


© Jeff Rose - REP 
) Diane Henson - DEM 


District Judge, 147th Judicial 
District 


(Juez del Distrito, 
istrito Judicial Núm. 147) 


AB precincts / Precntos enteros. 
3 Cliff Brown - DEM 
rr 201st Judicial 


Puer del Distrito 
Judicial Núm. 201) 


AB precincts / Precintos enteros. 

2 Amy Clark Meachum - DEM 
District Judge, 250th Judicial 
District 
[E del Distrito, 

Judicial Núm. 250) 
AB preancts / Precntos enteros. 

3 Karin Crump - DEM 
District Judge, 261st Judicial 
District "on 
(rie del Distrito, 

Judicial Núm. 261) 
Al precncto / Precintos enteros 


1 Lora Livingston - DEM 


District Judge, 299th Judicial 


(uez del Distrito, 
Judicial Nam, 299) 


All precincts / Precintos enteros. 

T Karen Sage - DEM 
District Judge, 331st Judicial 
District 
(Oe pto: 

Judicial Núm, 331) 
All preancts / Precatos enteros 

E David Crain - DEM 
District Judge, 403rd Judicial 
District 
(Juez del Distrito, 

Distrito Judicial Núm. 403) 

AJ preancts / Precintos enteros 
Brenda P. Kennedy - DEM 

District Judge, 419th Judicial 

District 

Juez del Distrito, 

Judicial Núm. 419) 

All precincts / Precintos enteros. 

E Orlinda Naranjo - DEM 
County Judge 
(Juez del Condado) 

All precincts / Precmtos enteros 


L Mike McNamara - REP 
L- Sarah Eckhardt - DEM 
© Richard Perkins - LIB 


County Court at Law 1, 


{Come de Ley del Condado 1, Juez) 
All precincts / Precintos enteros 


T Todd Wong - DEM 
County Court at Law 2, 


(ark do Loy del Condado 2. vuez) 
An precincts / Precintos enteros 


T Eric Montgomery Snepperd - DEM 
County Court at Law 3, 


(Corte de Ley de! Condado 3, Juez) 
Ad precincts / Precantos enteros. 


T John Lipscombe - DEM 
County Court at Law 4, 


AAA Juez) 
All precincts / Precntos enteros. 


E Mike Denton - DEM 
County Court at Law 5, 


( de Ley del Condado 5, Juez) 
All precincts / Precintos enteros. 


T Nancy Hohengarten - DEM 
County Court at Law 6, 


( de Ley del Condado 6, Juez) 
AB precincts / Precintos enteros. 


C Brandy Mueller - DEM 
County Court at Law 7, 


(Corte de Ley del Condado 7, Juez) 
All precincts / Precintos enteros 


(> Elisabeth Earle - DEM 


Judge, County Probate 
Court i 

(Juez, Corte Testamentaria 
del Condado) 

AN precincts / Precintos enteros 


2 Guy Herman - DEM 


District Clerk 
(Secretario del Distrito) 
An precincts / Precntos enteros. 


| Velva L Price - DEM 
2 Kevin Pick - LIB 


q Dana DeBeauvoir - DEM 
7 Michael M. Holt - LIB 
3 Wiliam E. Stout, Jr. - GRN 
County Treasurer 
(Tesorero del Condado) 
Ail procincta / Procinos enteros. 


2 Dolores Ortega Carter - DEM 
2 Mike Burris - LIB 


Precincts / Frecíntos: 401, 402, 403, 404, 405, 
408, 407, 408, 409, 410. 411, 412,413 414, 
415, 416, 417, 418. 419, 420, 421, 422. 423, 
424,425. 426, 427, 428. 429, 430, 431, 432. 
433, 434, 435. 436, 437. 438, 439, 440, 441 
442,443, 444, 446, 447. 448, 450, 451, 452. 
454,458, 460, 461. 463 


| Margaret J. Gomez - DEM 
2 Joseph Morse - LIB 


Precinct 1, 
Justice of the Peace 


Precincts / Precintos. 101, 102. 103, 105, 108. 
107, 108, 142. 113, 114, 116, 117, 118, 119, 
120, 121, 122, 124,125. 126, 127, 128, 129, 
130, 131, 132, 134, 139, 140, 141, 149, 191. 
152, 153, 154, 156, 164, 226, 227 


| Yvonne M. Williams - DEM 


Precincts / Precintos. 104, 109, 110, 111, 123, 
135, 137, 145, 146, 148, 150, 160, 161, 163, 
203. 205, 207, 209, 211, 215, 216. 216, 219, 


222, 225, 228, 229 232, 244, 245, 246, 247 

249, 253, 254, 256, 259. 260, 262. 263. 267 

268. 305, 306, 312 319. 320, 321. 323. 326, 

327. 328. 331,393, 334, 395, 336, 337, 343, 

345, 359, 369. 370.371, 372. 373. 374,375 
] Glenn Bass - REP 


2 Randall Slagle - DEM 
3 Daniel Martin Ruble - LIB 


Precinct 3, 
Justice of the Peace 


E Susan Steeg - DEM 
E Nathan Kleffman - LIB 


Precinct 4, 
Justice of the Peace 
(Precinto Núm. 4, 


Precinct 5, 

Justice of the Peace 
(Precinto Núm. 5, 
Juez de Paz) 
Preancts / Precintos: 133, 1 

206, 208, 210. 213, 214, 217, 220, 223, 
231, 233, 234, 235, 236, 237, 238. 239, 240, 
241, 242, 243, 248, 250, 251, 252. 256, 266. 
273.274, 275. 277, 311,313, 325, 329 


E Herb Evans - DEM 
Proposed Constitutional 
Amend 


35, 142, 


providing for the use and 
dedication of certain money 
transferred to the state highway 
fund to assist in the completion of 
transportation construction, 
maintenance, and rehabilitation 
projects, not to include toll roads.” 


“La enmienda constitucional que 
establece el uso y dedicación 
de ciertos fondos transferidos al 
Fondo Estatal de Carreteras para 
ayudar a finalizar la construcción, 
mantenimiento y rehabilitación 
en relación con el transporte, no 
incluye caminos de peaje.” 
C For/A Favor 
1 Against / En Contra 


Comprehensive Ballot — City Elections 


Travis County Clerk Elections Division 


November 4, 2014 Joint General and Special Elections 
Austin, Creedmoor, Jonestown, Pflugerville, Rollingwood, Village of Point Venture and Village of Volente. 
If you do not know your election precinct or need other election information, call the Travis County Clerk 
Elections Division at (512) 238-VOTE (8683). www.traviscountyelections.org 


Division de Elecciones de la Secretaria del Condado de Travis 


el 4 de noviembre de 2014 Elecciones Generales y Especiales Conjuntas 
Austin, Creedmoor, Jonestown, Pflugerville, Rollingwood, Aldea de Point Venture y Village of Volente. 
Sí usted no sabe su precinto de elección o para más información sobre la elección, llame a la División de Elecciones 
de la Oficina de la Secretaria del Condado de Travis (512) 238-VOTE (8683). www.traviscountyelections.org 


CITY OF AUSTIN SPECIAL AND 
GENERAL MUNICIPAL ELECTION 


(ELECCIÓN MUNICIPAL ESPECIAL Y 
GENERAL CIUDAD DE AUSTIN) 


MAYOR, CITY OF AUSTIN 
(ALCALDE, CIUDAD DE AUSTIN) 
All or portions of these precincts / (Precintos enteros o partes 


de estos precintos): 101, 102, 103, 104, 105, 106, 108, 109, 111, 


112, 113, 116, 117, 118, 120, 121, 122, 124, 125, 126, 127, 128, 
129, 130, 131,132, 133, 134, 135, 139, 140, 141, 142, 148, 149, 


151, 152, 153, 154, 156, 160, 164, 200, 202, 203, 205, 206, 207, 


208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 


221, 222, 223, 224, 225, 226, 227, 228, 231, 232, 233, 234, 235, 
236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 
249, 250, 251, 252, 253, 254, 256, 258, 259, 260, 262, 263, 266, 
267, 268, 273, 274, 275, 277, 301, 302, 303, 304, 305, 307, 309, 


310, 311, 312, 313, 314, 315, 317, 318, 321, 323, 324, 325, 326, 


327, 326, 329, 330, 331, 332, 333, 334, 335, 336, 337, 336, 339, 
MO, 341, 342, 343, 344, 345, 347, 349, 350, 351, 352, 354, 356, 
358, 359, 360, 362, 363, 364, 365, 366, 367, 368, 374, 375, 401, 


402, 404, 405, 406, 407, 408, 409, 410, 411, 412, 413, 414, 415, 


416, 417, 419, 420, 421, 422, 423, 424, 425, 426, 427, 428, 429, 
430, 431, 432, 433, 434, 435, 436, 437, 438, 439, 440, 441, 442, 


443, 444, 446, 447, 448, 450, 451, 452, 454, 458, 460, 461, 463 


N Mary Catherine Krenek 
N Todd Phelps 
1 Ronald Culver 
N Mike Martinez 
N Randall Stephens 
N Sheryl Cole 
N David Orshalick 
N Steve Adler 


DISTRICT 1, AUSTIN CITY COUNCIL, 
CITY OF AUSTIN 
(DISTRITO 1, CIUDAD DE AUSTIN 


CONSEJO, CIUDAD DE AUSTIN) 
All or portions of these precincts / (Precintos enteros o partes 


de estos precintos): 101, 102, 103, 104, 105, 106, 108, 117, 118, 


120, 121, 122, 124, 125, 126, 127, 128, 129, 130, 131,132, 133, 
134, 139, 141, 151, 153, 154, 156, 203, 206, 227, 325, 444 


N George Hindman 

N Sam Osemene 

N Christopher Hutchins. 

N DeWayne Lofton 

Valerie Menard 
Norman A. Jacobson 

N Michael Cargill 

N Ora Houston 

N Andrew Bucknall 


DISTRICT 2, AUSTIN CITY COUNCIL, 
CITY OF AUSTIN 
(DISTRITO 2, CIUDAD DE AUSTIN 


CONSEJO, CIUDAD DE AUSTIN) 
All or portions of these precincts / (Precintos enteros o partes 


de estos precintos): 116, 401, 402, 404, 405, 407, 410, 411, 413, 


423, 425, 443, 447, 448, 450, 451, 452, 463 


N Edward “Wally” Reyes 
N John C. Sheppard 

N Delia Garza 

N Mike Owen 


DISTRICT 3, AUSTIN CITY COUNCIL, 

CITY OF AUSTIN 

(DISTRITO 3, CIUDAD DE AUSTIN 

CONSEJO, CIUDAD DE AUSTIN) 

All or portions of these precincts / (Precintos enteros o partes 
de estos precintos): 407, 409, 420, 423, 424, 426, 427, 429, 430, 
431, 432, 433, 434, 436, 438, 439, 440, 441, 442, 446 


N Ricardo Turullols-Bonilla 
N Kent Phillips 
N Christopher Hoerster 
N Shaun Ireland 
N Mario Cantu 
M Jose Quintero Sr. 
N Fred L. McGhee 
N Jose Valera 
N Eric J. Rangel 
N Susana R. Almanza 
1 Sabino "Pio" Renteria 
N Julian Limon Fernandez 


DISTRICT 4, AUSTIN CITY COUNCIL, 

CITY OF AUSTIN 

(DISTRITO 4, CIUDAD DE AUSTIN 

CONSEJO, CIUDAD DE AUSTIN) 

All or portions of these precincts / (Precintos enteros o partes 


de estos precintos): 133, 135, 139, 140, 142, 149, 156, 164, 209, 


211, 217, 218, 222, 223, 224, 258, 260, 268 


N Roberto Perez, Jr. 
| Louis C. Herrin, til 
N Sharon E. Mays 
N Monica A. Guzman 
| Marco Mancillas 
N Gregorio "Greg" Casar 
N Katrina Daniel 
N Laura Pressley 


DISTRICT 5, AUSTIN CITY COUNCIL, 
CITY OF AUSTIN 
(DISTRITO 5, CIUDAD DE AUSTIN 


CONSEJO, CIUDAD DE AUSTIN) 
All o portions of these precincts / (Precintos enteros o partes 


de estos precintos): 309, 310, 332, 340, 342, 344, 350, 352, 406, 


408, 411, 412,414, 415, 416, 417, 419, 430, 435, 447, 454, 458, 
460, 461, 463 


N Jason Denny 

N Dave Floyd 

N Mike Rodriguez 

N Ann Kitchen 

N CarolAnneRose Kennedy 
N Dave Senecal 

N Dan Buda 


DISTRICT 6, AUSTIN CITY COUNCIL, 

CITY OF AUSTIN 

(DISTRITO 6, CIUDAD DE AUSTIN 

CONSEJO, CIUDAD DE AUSTIN) 

All or portions of these precincts / (Precintos enteros o partes 


de estos precintos): 207, 232, 234, 244, 245, 254, 267, 312, 318, 


324, 333, 334, 335, 336, 343, 359, 374, 375 


N James “Jimmy” Flannigan 
7 Lloyd “Pete” Phillips 
1 Don Zimmerman 
N Jay Wiley 
N Matt Stilwell 
N Mackenzie Kelly 


DISTRICT 7, AUSTIN CITY COUNCIL, 
CITY OF AUSTIN 
(DISTRITO 7, CIUDAD DE AUSTIN 


CONSEJO, CIUDAD DE AUSTIN) 

All or portions of these precincts / (Precintos enteros o partes 
Ge estos precintos): 109, 111, 112, 113, 148, 160, 205, 207, 211 
215, 216, 218, 219, 225, 226, 228, 235, 236, 239, 241, 242, 243, 
248, 252, 258, 259, 260, 263, 268 


N J.E "Jeb" Boyt 

N Zack Ingraham 

M Melissa Zone 

N Ed English 

N Darryl R. Wittle 

N Jimmy Paver 

M Leslie Pool 

M Pete A. Salazar, Jr. 


DISTRICT 8, AUSTIN CITY COUNCIL, 
CITY OF AUSTIN 
(DISTRITO 8, CIUDAD DE AUSTIN 


CONSEJO, CIUDAD DE AUSTIN) 

All of portions of these precincts / (Precintos enteros o partes 

de estos precintos): 301, 302, 303, 304, 307, 314, 315, 317, 330, 
338, 339, 347, 349, 351, 354, 356, 358, 360, 362, 363, 364, 365, 
366, 367, 368 


N Ellen Troxclair 
N Ed Scruggs 

N Becky Bray 

N Darrell Pierce 
N Eliza May 


DISTRICT 9, AUSTIN CITY COUNCIL, 
CITY OF AUSTIN 
(DISTRITO 9, CIUDAD DE AUSTIN 
CONSEJO, CIUDAD DE AUSTIN) 
All or portions of these precincts / (Precintos enteros o partes 
de estos precintos): 133, 135, 152, 200, 202, 206, 208, 214, 250, 
274,275, 277, 311, 313, 329, 341, 420, 421, 422, 424, 428, 429, 
433, 437 

N Erin McGann 

N Kathie Tovo 

N Chris Riley 


DISTRICT 10, AUSTIN CITY COUNCIL, 
CITY OF AUSTIN 
(DISTRITO 10, CIUDAD DE AUSTIN 


CONSEJO, CIUDAD DE AUSTIN) 

All or portions of these precincts / (Frecintos enteros o partes 

de estos precintos}: 210, 212, 213, 214, 220, 221, 231, 233, 237, 
238, 240, 246, 247, 249, 251, 253, 256, 262, 266, 273, 274, 305, 
321, 323, 326, 327, 328, 331, 337, 338, 345, 364 


N Matt Lamon 

N Bill Worsham 

N Tina Cannon 

N Margie Burciaga 
N Robert Thomas 
N Sheri Gallo 

MN Mandy Dealey 
N Jason Meeker 


CITY OF AUSTIN, BOND ELECTION 
(ELECCION DE BONOS 
CIUDAD DE AUSTIN) 


All or portions of these precincts / (Precintos enteros o partes 
de estos precintos): 101, 102, 103, 104, 105, 108, 109, 111, 112, 
113, 116, 117, 118, 120, 121, 122, 124, 125, 126, 127, 128, 129, 
130, 131,132, 133, 134, 135, 139, 140, 141, 142, 149, 151, 152, 
153, 154, 156, 160, 164, 200, 202, 203, 205, 206, 207, 208, 209. 
210,211, 212, 213, 214, 215, 216. 217, 218. 220. 221, 222, 223, 
224, 226, 227, 228, 231, 232, 233, 234, 235, 236, 237, 238, 239, 
240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252. 
253, 254, 256, 258, 259, 260, 262, 263, 266, 267, 268, 273, 274, 
275, 277, 201, 302, 303, 304, 305, 307, 309, 310, 311, 312, 313, 
314, 315, 317, 318, 321, 323, 324, 325, 326, 327, 326, 329, 330, 
331, 332, 333, 334, 335, 336, 337, 338, 339, 340, 341, 342, 343, 
344, 345, 347, 349, 350, 351, 352, 354, 356, 358, 359, 360, 362, 
263, 364, 265, 366, 367, 374, 375, 401, 402, 404, 405, 406, 407, 
408, 409, 410, 411, 412, 413, 414,415, 416, 417, 419, 420, 421, 
422, 423, 424, 425, 426, 427, 426, 429, 430, 431, 432, 433, 434, 
435, 436, 437, 438, 439, 440, 441, 442, 443, 444, 445, 447, 448, 
450, 451, 452, 454, 458, 460, 461, 463 

PROPOSITION, CITY OF AUSTIN 

The issuance of $600,000,000 bonds and notes for rail 
systems, facilities and infrastructure, including a fixed 

rail transit system to be operated by Capital Metropolitan 
Transportation Authority (which may spend its funds to 
build, operate and maintain such system) servicing the 
East Riverside Corridor, downtown Austin, the State 
Capitol complex, the Medical School complex, the 
University of Texas, Hancock Center, Austin Community 
College Highland campus, and surrounding 
neighborhoods, and roadway improvements related to 
such rail systems, facilities and infrastructure; provided 
that the City may not issue bonds or notes to pay costs of 
the fixed rail transit system (other than expenditures for 
planning, designing and engineering necessary to obtain 
grant and/or match funding) unless (i) the City obtains 
grant or match funding for the cost of the fixed rail transit 
system from the Federal Transit Administration or one 

or more other federal or state sources and (ii) the City 
provides funding in an amount not less than $400,000,000 
to pay costs of roadway improvement projects of regional 
‘significance that are designed to relieve congestion, 
enhance mobilty and manage traffic in the 1-35, US 183, 
SH 71, RM 620, RM 1826, RM 2222, FM 734 (Parmer), 
Lamar Boulevard, and Loop 360 corridors; and the levy of 
a tax sufficient to pay for the bonds and notes. 


(PROPOSICION, CIUDAD DE AUSTIN) 

La emisión de $600,000,000 en bonos y pagares para 
sistemas ferroviarios, facilidades, e infraestructura, 
incluyendo un sistema de transito sobre rieles fijos 
operado por Capital Metropolitan Transportación 
Authority (quien podrá gastar sus fondos para construir, 
operar y mantener dicho sistema) para servicio al 
corredor East Riverside Corridor, a la Zona Centro de 
Austin, al Complejo Estatal del Capitolio, al Complejo 

de la Escuela de Medicina, a la Universidad de Texas, a 
Hancock Center, al campus Highland de Austin 
Community College, y a los vecindarios circunvecinos 

y para mejoras de calles y carreteras relacionadas con 
dichos sistemas ferroviarios, facilidades e infraestructura 
siempre y cuando la Ciudad no podrá emitir bonos ni 
pagares para pagar costos del sistema de transito sobre 
rieles fijos (que no sean gastos para planificación, diseño 
e ingeniería necesarios para obtener financiamiento de 
concesiones y/o de contrapartida/malching) a no ser que 
(i) la Ciudad obtenga fondos de concesiones o 
contrapartida/matching para el costo del sistema de 
transito sobre rieles fijos de la Administración Federal de 
Transito (Federal Transit Administration) o de uno o 

más recursos federales o estatales y (ii) la Ciudad 
proporcione financiamiento en una cantidad que no sea 
menos de $400,000,000 para pagar el costo de 
proyectos de mejoras de calles y carreteras de 
transportación de significancia regional que se hayan 
diseñado para aliviar congestionamientos, realzar la 
movilidad y manejar el tráfico en los corredores de 1-35, 
US 183, SH 71, RM 620, RM 1826, RM 2222, FM 734 
(Parmer), Lamar Boulevard, y Loop 360. y la imposición 
de un impuesto suficiente para pagar los bonos y 
pagarés. 


n For / A Favor 
1 Against / En Contra 


CITY OF CREEDMOOR 
GENERAL ELECTION 


(CIUDAD DE CREEDMOOR 
ELECCIÓN GENERAL, 


All or portions of these precincts / (Precintos enteros o partes 
de estos precintos): 403, 404 


BOARD OF ALDERMEN, CITY OF CREEDMOOR 
(JUNTA DE CONCEJALES, CIUDAD DE 
CREEDMOOR) 

Vote for none, one, two or three (Vote por ninguno, uno, 
dos o tres) 


N Richard E. Harrison 
N Connie Meador Horn 
M Jeff Jakobeit 
M Milissa Berry 

1 James Stinson 
M Jesse Solis 


CITY OF JONESTOWN 
GENERAL ELECTION 


(ELECCIÓN GENERAL 
DE CIUDAD DE JONESTOWN) 


AB oF portions of these precincts / (Precintos enteros o partes 
de estos precintos): 369, 371, 372, 373, 375 


PLACE 3, ALDERMAN, CITY OF JONESTOWN 
(LUGAR 3, CONCEJAL, 
CIUDAD DE JONESTOWN) 


nm Joseph D. Aaron 
M Sarah Heihn 


PLACE 4, ALDERMAN, CITY OF JONESTOWN 
(LUGAR 4 CONCEJAL, 
CIUDAD DE JONESTOWN) 

T Dave Nelsen 


PLACE 5, ALDERMAN, CITY OF JONESTOWN 
(LUGAR 5, CONCEJAL, 
CIUDAD DE JONESTOWN) 


n Paul Johnson 


CITY OF PFLUGERVILLE 
GENERAL ELECTION 


(ELECCION GENERAL 
CIUDAD DE PFLUGERVILLE) 


AB or portions of these precincts / (Precintos enteros o partes 
de estos precintos): 105, 107, 110, 113, 123, 136, 137, 145, 146, 
148, 150, 160, 161, 163, 203, 219 


PLACE 2, COUNCIL MEMBER, 

CITY OF PFLUGERVILLE 

(LUGAR 2, MIEMBRO DEL CONCILIO, 
CIUDAD DE PFLUGERVILLE) 


N Brad Marshall 
N Rudy Metayer 


PLACE 4, COUNCIL MEMBER, 

CITY OF PFLUGERVILLE 

(LUGAR 4, MIEMBRO DEL CONCILIO, 
CIUDAD DE PFLUGERVILLE) 


N Starlet D. Sattler 


CITY OF PFLUGERVILLE 
BOND ELECTION 


(ELECCIÓN DE BONOS 
CIUDAD DE PFLUGERVILLE) 


PROP. 1, CITY OF PFLUGERVILLE 

The issuance of $28,000,000 tax bonds for City street 
improvements, including for E. Pecan Street, Pflugerville 
Parkway, Heathermide Boulevard, Weiss Lane, Rowe 
Lane, Pfennig Lane, Cactus Blossom Drive, Columbine 
Street Ardisia Drive, Simsbrook Drive, Dashwood Creek 
Drive, Blackhorn Drive, Thackeray Lane, Gravesbend 
Road, Isle of Man Road, Isle of Man Court, Gower Street 
and Langland Road. 


(PROP. 1, CIUDAD DE PFLUGERVILLE) 

La emisión de bonos de impuestos por $26,000,000 para 
mejoras de las calles de la ciudad, que incluyen para 

E. Pecan Street, Pflugerville Parkway, Heatherwilde 
Boulevard, Weiss Lane, Rowe Lane, Pfennig Lane, 
Cactus Blossom Drive, Columbine Street, Ardisia Drive, 
Simsbrook Drive, Dashwood Creek Drive, Blackhorn 
Orive, Thackeray Lane, Gravesbend Road, Isle of Man 
Road, Isle of Man Court, Gower Street y Langland Road. 


N For / A Favor 
N Against / En Contra 


PROP. 2, CITY OF PFLUGERVILLE 

The issuance of $25,000,000 tax bonds for City park and 
recreational purposes, including development of parks 
and hike and bike trails, a City Sports Complex and parks 
and recreational improvements at Lake Pflugerville. 


(PROP. 2, CIUDAD DE PFLUGERVILLE) 

La emisión de bonos de impuestos por $25,000,000 para 
parques y fines recreativos de la Ciudad, que incluyen el 
desarrollo de parques y sendas para caminar y para 
bicicletas, un Complejo Deportivo para la Ciudad y 
mejoras a parques e instalaciones recreativas en Lake 
Pflugerville, 


n For / A Favor 
N Against / En Contra 


CITY OF ROLLINGWOOD 
GENERAL ELECTION 
(ELECCIÓN GENERAL 
CIUDAD DE ROLLINGWOOD) 
All or portions of these precincts / (Frecinios enteros o partes 
de estos precintos): 307, 347 


THE FOLLOWING UNOPPOSED 
CANDIDATES ARE 
DECLARED ELECTED: 
(CANDIDATOS SIN OPOSICIÓN SON 
DECLARADOS ELECTOS): 


MAYOR, CITY OF ROLLINGWOOD 
(ALCALDE, CIUDAD DE ROLLINGWOOD) 


Thom Farrell 


ALDERMAN, CITY OF ROLLINGWOOD 
(CONCEJAL, CIUDAD DE ROLLINGWOOD) 


Roxanne McKee 


ALDERMAN, CITY OF ROLLINGWOOD 
(CONCEJAL, CIUDAD DE ROLLINGWOOD) 


Sara Hutson 


CITY OF ROLLINGWOOD 
SPECIAL ELECTION 


(ELECCION ESPECIAL 
CIUDAD DE ROLLINGWOOD) 


ALDERMAN, CITY OF ROLLINGWOOD 


(CONCEJAL, CIUDAD DE ROLLINGWOOD) 
Vote for none, one or two (Vote por ninguno, uno o dos) 


N Jordan Scott 
M Amy Pattillo 
N Colin MacDougal 


THE VILLAGE OF POINT VENTURE 
COUNCIL ELECTION 


(ELECCIÓN CONSEJO DE LA 
ALDEA DE POINT VENTURE; 


All or portions of these precincts / (Precinios enteros o partes 
de estos precintos): 373 
COUNCIL, VILLAGE OF POINT VENTURE 


(CONSEJO, LA ALDEA DE POINT VENTURE) 
Vote for none, one, two or three (Vole para ninguno, uno, 
dos, o tres) 


N Dan Deveze 

N Bill Roney 

M Lisa Guest 

N Michael Sutton 


VILLAGE OF VOLENTE 
GENERAL ELECTION 


(ELECCIÓN GENERAL 
VILLAGE DE VOLENTE) 


All or portions of these precincts / (Frecinios enteros o partes 
de estos precintos): 375 

MAYOR, VILLAGE OF VOLENTE 

(ALCALDE, VILLAGE DE VOLENTE) 


N Ken Beck 


COUNCIL MEMBER, VILLAGE OF VOLENTE 


(CONCEJO MUNICIPAL, VILLAGE DE VOLENTE) 
Vote for none, one or two (Vole por ninguno, uno o dos) 


M David Springer 
N Kristi Belote 
N Bill Connors 


Attachment 8 
STAR-VOTE™ CRYPTOGRAPHIC ASPECTS PAPER 


Star- Voten Cryptographic Aspects 


Josh Benaloh, Microsoft Research 
and Olivier Pereira, Université Catholique de Louvain 


Modified by Bryce Eakin for consistency with Travis County requirements 


1. ELECTION PROCESS 


1.1. Entities 
This paper presumes 3 parties assuming 3 different roles: 


Voters submit votes and want to be able to perform various audit operations. 
Trustees compute the election outcome and are responsible for the privacy of the votes. 


Internal Auditors are responsible for doing internal audit operations. This role in 
particular includes running a risk-limiting audit. 


This paper also presumes 4 devices assuming 4 different roles: 


Voting Stations interact with the voters in order to produce ballots, under electronic and 
paper format. 


Ballot Box/Scanners receive the paper ballots and notify Ballot Control Station of this 
reception. 


Auditing Station can be used by the voter to challenge ballot-marking devices. 
Ballot Control Stations (BCS) orchestrate the various devices in a voting office. 


1.2. Setup 
The following values are created and published before the election starts. 


(1) Trustees produce an election public key kr for a threshold commitment consistent 
encryption scheme [6]. 

(2) — Each BCS produces a public key kç, for an encryption scheme. 

(3) Two unique hash chain seeds zpo and zio, one for the public audit part and one for the 
internal audit part. These seeds are computed as cryptographic hashes of a string 
representing in a unique, unambiguous and unpredictable way the description of the 
election, to which is concatenated a special string indicating the chain in which that seed 
must be used. 


The unpredictability may be produced by a variety of methods that generate a random 
outcome on election morning in each polling station; pollworkers then enter the outcome 
into the controller.. 


All voting stations are initialized with kr, kc, _,,, zpo, Zio. The ballot boxes are initialized 


with kc, _,,, 7poand Zio. 


1.3. Voter identification 


When signing-in, a voter receives a token £ associated to his ballot style bst. This token is 
made in such a way that it can be used only once. Recovery procedures are decided in the 
case a voter claims that his token was consumed by a Voting Station that did not return a 
paper ballot. 


1.4. At the Ballot Marking Device 


When entering the booth, the voter enters his token and the Voting Station displays an 
empty ballot of style bst, so that the voter can make his selection v. 


The Voting Station processes these choices as follows: 


It broadcasts the information that the token introduced by the user is consumed. 

It selects an unpredictable ballot identifier pid, (e.g., as a UUID) for each page which 
will ultimately be printed as part of the paper voting record. These pid, must be kept 
secret and will be part of the risk limiting audit trail. 

It selects a unique page casting identifier pcid, (possibly as the concatenation of the 
mid and a counter) for each page of the paper voting record. This pcid, will be used to 
track MESE the ballot page made its way to a ballot box. 

= = Enck (pcido l- Il pcid,,), for each BCS, i, which will be used 


by BCS i to link the paper pages and electronic record. For simplicity, Cis will refer 


It computes ae cid 


to the vector of these a S; hia I -ll al: 
For each page p of the final PVR, it computes Cy, = CCENC gy (Vp, ZPo) where vp is the 


subset of the voter’s selections which will appear in the PVR on that page. For 
convenience, cy will refer to the vector of these Cop Ss. 


It computes a vector Cpcig Of ciphertexts that encrypt H (bcid, I ri) with kr for each 
race rj, using the pcid, for the page of the PVR on which that race will ultimately be 
printed. 

It broadcasts a message that contains the identifier of the voting station, mid, the time 
t, bst, Coad: Cpcia» Cv and a hash zi; := H (zi;_1, mid, t, bst, Ceid Cpid» Cy) for 
inclusion in the internal audit trail. 

It prints a paper voting record, potentially consisting of more than one page, as well as 
a receipt. Each page of the paper voting record contains a human readable summary of 
v and a machine readable version (as a 1D barcode) of pid,, pcid,, and the ballot style 
bst (if the ballot is made of multiple pages, then the page number is concatenated to 
the bst). The second part is a take home receipt that contains a human readable version 
of the election description, the time ¢ and zp; := H (zpi-1, mid, t, CCExt(c,)). In 
order to simplify the audit process, the first 5 symbols of zp; are printed in bold and a 
bit separated from the other symbols. At verification time, the voter will then be 
invited to search for his receipt based on these 5 characters and to check whether the 
reply contains the rest of the hash. 


When receiving this, each BCS decrypts ee a and appends the pair (pcid,, zp;) into a local 


table, until a ballot with that pcid, is scanned at the ballot box. Note that this table should 
not appear in any log, as being able to link a pcidp to a specific time and that time to the time 
at which a voter submitted a specific ballot could violate the vote privacy during the internal 
audit process. In case of problems, the encrypted version of the pcid, still appears in all logs, 
which should provide the information needed if an investigation is required. 


1.5. Challenging the Ballot Marking Device 


If the voter wants to challenge the BMD, he brings the PVR to a poll worker. The poll 
worker now proceeds as follows: 


— He physically stamps the PVR to mark it as spoiled, and ideally links its different 
pages (including the receipt) together in such a way that no one will be able to rebuild 
a full ballot from parts of different ballots in an unnoticeable way (possibly by 
stamping a unique serial number on all parts of the ballot). This makes that ballot 
usable as evidence in case of a cheating Voting Station. Using specially designed 
paper would be desirable as well, in order to make forgeries harder. 

— He scans the pcid, for each page, so that the ballot is recorded to be spoiled. This 
recording process happens in the same way as a normal casting process, except that a 
“spoiled” flag appears in all messages included in the hash chain. (This scanning step 
is optional. Its goal is to facilitate, as a human factor verification, the counting of the 
number of spoiled ballots against the number of voters who leave the voting office 
without casting their ballot.) — He gives the PVR back to the voter. Any PVR (or 
pages of a PVR) not placed in a ballot box are presumed to have been implicitly 
spoiled. 


Later, at tallying time, the spoiled vote records will all be decrypted and posted on a bulletin 
board for voter verification. If only a subset of a voter’s PVR pages were placed in a ballot 
box, the remaining pages are considered spoiled and their associated races decrypted and 
posted on the bulletin board for voter verification. Any voter who sees either that his ballot 
does not appear decrypted on the board, or that the published decryption does not match the 
human readable choices on his PVR, is invited to complain. 


1.6. Casting a Ballot 


If the voter is happy with the selections printed by the Voting Station, he brings the PVR to 
a ballot box. There, each page of the PVR is placed into the ballot box, while the take-home 
receipt is kept by the voter. 


The ballot box computes a vector Cocido = (Encke, (pcidp) Ie I| Encke, (pcidp)) for 
each page and sends it to the BCSs, together with zi; = H (zi;_,, t, uid, Chola): Each BCS 
decrypts cis dp and searches for pcidp in its local ballot table. If pcid, is not in the table, it 


triggers an alert. Otherwise, if it finds a (pcidy, Zp;) pair in its table, removes it from the 
table, and broadcasts z, p, and zi; = H (zi;_,, t, cid, z, p) which indicates that page p of the 
vote record that is associated to z in the hash chain has been cast and must be included in the 
tally. 


1.7. Tallying Process 
At the end of the day, all Cop that have been marked as to be included for the tally are 
checked for validity and aggregated into an encryption cy of the tally. This tally is then 


jointly decrypted by the Trustees and published. (This is done as needed for the different 
races, ballot styles, ... ) 


Then, CCExt( ) is applied to all Cop ciphertexts and the result is published with all the 


information needed to check the zp hash chain, and the trustees publish the information that 
is needed to prove that the tally is consistent with the CCExt(c,,)’s. 


In addition, the Trustees also jointly verifiably decrypt and publish the content of all Cop 
corresponding to spoiled pages of PVRs. 


1.8. Audit of the Electronic Process 


Anyone can perform a number of verifications from the published information: 


(1) check the validity of the published CCExt(c,,)’s; 
(2) check that the tally is consistent with the published CCExt(c,,,)’s; 


(3) check the validity of the zp hash chain; 
(4) check the number of ballots against the number of voters if the information is public. 


Furthermore, voters are invited to check whether the zp; value printed on their receipt 
appears in the list of ballots included in the tally. 


All published information is available through an easy to access web API in order to ease 
the design of independent auditing tools, but also as a big signed document that commits the 
election organizers on the posted values. 


If any of these verification procedures fails, a voter may complain. 


1.9. Audit of the Paper Ballots 


After having checked the validity of all the ballots, but before decrypting the election 
outcome, the Trustees supervise (or perform), contest by contest, a shuffle of all (Cpia, Cp) 
pairs corresponding to valid ballots, yielding a list of (Cpia, Cy) pairs. This shuffle is 
performed in an optimistic way and does not need to be verifiable. As a result, it can be 
performed extremely efficiently: all reencryption ciphertexts can be precomputed as 
Enc;,.(0), leaving only a bunch of multiplications to be performed at tallying time. 


After completion of this shuffle, the Trustees decrypt all «”, and cpcia tuples, at the same time 
as they decrypt the election outcome. This decryption yields, for each race rj, a list that 
contains H (pcid, Il ri) and the cleartext choices that should be those on the paper vote 
record page pcidp for race ri. This table is made available to all people and observers who 
take part to the risk-limiting audit. Note that, thanks to the use of the hash function, no one 
is able to decide which race results belong to the same ballot: this can only be recovered by 
someone who knows the pcid,, which can be learned from the paper vote records. But, in 
that case, the full ballot is exposed anyway. 


From this table, a risk limiting audit can take place. One way of doing this audit is as 
follows. Make sure that all hashes are unique and that the table contains as many races as 
are on the paper ballots, then repeat as long as decided for the audit: 


(1)  verifiably select a random paper ballot in the urn; 


(2) read its pcid» and search for H (pcid,, Il ri) values in the table for all races r; present 
on the ballot; 
(3) compare the corresponding plaintexts to the paper ballot. 


Proper care should also be taken to make sure that it is not feasible to inspect all paper 
ballots in search of a specific pattern. 


2. CRYPTOGRAPHIC ALGORITHMS 
For practical use, targets are established using: 


— Encryption schemes that come with a simple distributed/threshold key generation procedure, 
in order to simplify and limit the risks of error. In this context, encryption schemes that 
allow computing in prime order groups are of special interest. 

— A security level equivalent to at least 256-bits. This applies for the output size of hash 
functions (e.g., SHA256 or Keccak) and the order of the groups in which the system 
operator would compute (see [9] for instance.) 


Some concrete proposals are discussed below. 


2.1. Key generation 


Groups with a public generator of prime order q are used. In all the schemes, the public key 
is a sequence of elements of the form g* and the private key is a sequence of corresponding 
x, possibly shared between a set of key holders. 


This can be done in a very simple way in the case of distributed (non-threshold) key 
generation. Let U4, ..., Un be the set of key holders and / be a unique election identifier. U; 
proceeds as follows: 


(D) select (x; ri) € Zé; 
(2) publish g*:, and the Schnorr proof made of c; = H(l, g*, g") and f; = 1, + C¡X;. 


Everyone can now verify that ci = H(l, g%, g‘‘/(g*‘)*) and compute the public key 
element as g* =] |; g^i- 


The key benefit of this approach is that it requires a single round by the key holders and 
does not require any private communication between key holders. A single key loss is 
however sufficient to make it infeasible to decrypt any ciphertext. Various threshold key 
generation procedures exist but are much more demanding [8]. 


The goal is to have a commitment-consistent encryption scheme for the Trustees, that makes 
it simple to have verifiable encryption and decryption procedures. 


2.2. Encryption of 0/1 values 


The scheme must also be additively homomorphic and it should be feasible to decrypt the 
sum of all votes efficiently. 


The most effective way to do this seems to encrypt all choices independently and, for 
validity, to prove that each ciphertext encrypts a 0 or a 1 (assuming approval voting). All 
unregistered write-ins can be aggregated in a single candidate, which prevents having a full 
count for them individually. Ideally, the number of votes write-ins will get will be small 
enough to not require decrypting write-in ciphertexts in the end. 


There are (at least) two ways to verifiably encrypt and decrypt a 0 or a 1. The first involves 
simpler algebraic operations (basic modular arithmetic is sufficient) but is less robust from a 
confidentiality point of view. The second offers stronger resilience to mistakes by Trustees, 
hacking and advances in computational power and cryptanalysis, but involves more 
sophisticated algebraic operations (elliptic curve point operations for voting and pairing 
evaluation for auditing.) 


2.2.1. ElGamal encryption 
The simplest choice for encryption is to use exponential ElGamal. 


— The public key is a single group element h = g* generated as suggested above, 
in a distributed or threshold way. 

— A choice mis encrypted as follows: choose r — Z¿ and compute (a, f) = 

(g",g™h"). 

— The fact that a ciphertext encrypts 0 or 1 is proven by adding the following 
disjunctive Chaum-Pedersen proof: select Cy — Z 2256 andf,_m © Zq, 
compute 
Aim = gm (a) and By =R (B/g* "Tm, select s — Zq, 
compute Am = g* and Bm = h5, then c = H(zpo, a, P, Ao, Bo, Ay, B1). 
Eventually, compute Cm = C — Cy_m and fm = S +Cmr. The proof is made of 
CoCr fo, fa- 

— Decryption proceeds by computing a decryption factor ô = a. Then, m can be 
computed as the discrete logarithm of 6/0 in basis g. 

— The correctness of the decryption can be proven by adding the following proof. 
Select s — Z¿, compute and publish c = H(zpo, a, 6,g°,h*) and f = s + cx. 


Several observations here: 


Group choice. The group used here can either be a 256 bits prime order subgroup of 
Zy where |p| = 2048 (or even 3248 for general long-term protection) or a 256 bits 
prime order group on an elliptic curve. Actual choices for these groups are proposed 
in various places (e.g., [10; 13]). Explicit formula for elliptic curve operations are 
widely available as well [4]. Elliptic curves require more sophisticated algebra but 
offer ciphertexts that are typically = 8—10 times smaller for the same security level. 


Discrete log extraction. Exponential ElGamal is used in order to have an additively 
homomorphic encryption scheme. As a result, the decryption procedure involves 
extracting a discrete logarithm (DL) in a fixed base. As the number of voters is an 
upper bound on this DL, an exhaustive search is easy. The full list of values can also 
be stored in a table in advance if desired. A middle ground consists in using Shanks’ 
baby-step giant-step algorithm. 


Distributed decryption. Distributed decryption can be done as follows: each key 
holder computes 6; = a*‘ and now mis the DL of B/J]; 6; in base g. Each key holder 
also needs to provide a Chaum-Pedersen proof of correct decryption. 


CCExt. The CCExt function is defined here as the identity function. As a result, when 
using ElGamal, the full ciphertexts are included as part of the public audit trail zp. 
This may result in a full loss of the privacy of the votes if the trustees somehow lose 
their keys, if a cryptanalytic breakthrough happens, or if people look at the records a 


few dozen years from now when computational power will have increased enough to 
break the encryption easily. 


2.2.2. PPATS encryption 


The PPATS scheme [6] makes it possible to have public audit trail perfectly hiding 
the votes, at the potential cost of more sophisticated algebraic operations. By using 
this scheme, the public audit trail does not risk violating the privacy of the votes if 
keys are revealed or encryption broken. 


This scheme uses 3 groups of the same prime order q: G4, G2 and Gr , in a setting 
where there is an asymmetric bilinear map e: G, X G > Gr . We use so-called 
Type-3 groups [7], so that the DDH problem on which the security of ElGamal relies 
is expected to be hard in these groups. We suppose that g1, g2 and gr generate G,, G3 
and Gr respectively. We furthermore assume that h21s a second generator of G, 
chosen randomly and independent of g2 (in practice, this can be done by computing h2 
deterministically as a cryptographic hash of g2 for instance). 


— The public key is a single group element h, = gf generated as suggested 
above, in a distributed or threshold way. 

— A choice mis encrypted as follows: choose r,s <- z and compute (a, p, y) = 
(gi, 91 hy, h? 92). 

— The fact that a ciphertext encrypts O or 1 is proven by adding the following 
proofs: 

— Choose Me, Te, Se — Z3 and compute (Ae, Be, Ce) = (g, gh, ny gs): The 
proof is made of ce = H (zpo, 0, P, Y, Ac, Be, Ce) and fo = (Me + Cem, ro + 
Ca Se + Ces); 

— select c1-m + Z32256 and fm <— Zq, compute Ci-m = gh yh n 
select rọ < Z,, compute Cm = do thenc = H(ZPo, Y, Co, C1). Eventually, 
compute Cm = C — Cy_m and fm = Yo + Cmr. The proof is made of co,c1,fo,f1. 

—  CCExt(a, B,Y, Co fer Co, C1 for fi) = U, Co Cr for fa) 

— Decryption proceeds by computing a decryption factoré = a*. Then, m can be 
computed as the discrete logarithm of e(9/f, 92) : e(g1,Y) in basis e(g1,h2). 

— The correctness of the decryption can be proven by publishing a = a*. (It can 
then be checked that e(B/a, 92) = e(g1,y/h4").) 


Several observations: 


Group choice. The most common curve choices offering the properties needed are the 
BLS curves [1; 5] or the BN curves [2; 14]. Various free implementations of the BN 
curve arithmetic are available [12; 11; 3]. 


CCExt. The CCExt function now extracts a single group element from the ciphertext, 
which perfectly hides the vote, as well as the 0-1 validity proof, which is perfectly 
hiding as well. So, whatever cryptography breakthrough or hacking of the trustees 
happens, the output of CCExt will not leak anything about the votes. 


2.3. Encryption of the pid 


It is necessary to encrypt larger values in various places and, most importantly, the pid 
which is a high entropy value, and needs to be homomorphically encrypted. The high 


entropy prevents using a scheme in exponential mode: it would not be possible to extract the 
final DL at decryption time. 
There are two ways to solve this: 


(1) Use ElGamal on elliptic curves (not in Z;): it is then easy to encode and decode 
integers as group elements. 

(2) Generate a second ElGamal key in a different group Z;, with p = 2q + 1 where q is 
a 2047 bits prime and p is equal to 3 mod 4. Then, squaring messages mod p is an 
easily decodable encoding of messages. Note that this group should not be used 
everywhere, as encryption becomes 8 times more expensive. 


This suggests that elliptic curve cryptography might be more convenient by limiting the 
number of keys. 
2.4. Encryption for the controller 


The encryption scheme used to send the pcid, to the BCS does not need any homomorphic 
property but needs to support efficient decryption. 


The solutions above can be used again here, as well as more traditional solutions if that 
eases the implementation (e.g., RSA encryption, or hashed ElGamal). 
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ATTACHMENT 9 
HUMAN FACTORS EVALUATION TEST BALLOT 


Test Ballot, Page 1 Test Ballot, Page 2 


PROPOSITIONS 


GENERAL ELECTION BALLOT 
HARRIS COUNTY, TEXAS 
NOVEMBER 4, 2008 


+ TO VOTE, COMPLETELY FILL IN THE OVAL@® NEXT TO YOUR CHOICE. 

+ Use only the marking device provided or a number 2 pencil. 

+ If you make a mistake, don't hesitate to ask for a new ballot. If you erase or make other 
marks, your vote may not count. 


PRESIDENTANDVICEPRESIDENT| STATE | COUNTY 


PRESIDENT AND VICE PRESIDENT COMMISSIONER OF GENERAL DISTRICT ATTORNEY 
(Vote for One) (Vote for One) 


LAND OFFICE 
O Gordon Bearce REP C) Sam Saddler REP O Corey Behnke 


(Vote for One) 
Nathan Maclean 
CJ Elise Elizey DEMI O Jennifer A. Lundeed 


COMMISSIONER OF AGRICULTURE] COUNTY TREASURER 
(Vote for One) (Vote for One) 
(>) Janette Froman 


Chris Aponte ES Polly Rylander rep] O Dean Caffee 


CONGRESSIONAL 
(3) Roberto Aron DEM (S Gordon Kallas 


UNITED STATES SENATOR 
SANE) RAILROAD COMMISSIONER SHERIFF 
© cecile cadieux (Vote for One) (Vote for One) 
(3) Stanley Saari 


DEI © Jason Valle 


O Vernon Stanley Albury 
Richard Rigby 


© Fern Brzezinski DEM O Jillian Balas 


© Corey Dery 


REPRESENTATIVE IN CONGRESS 
DISTRICT 7 
(Vote for One) 


O Pedro Brouse 


© Robert Mettler 


IND O Zachary Minick 


STATE SENATOR COUNTY TAX ASSESSOR 
(Vote for One) (Vote for One) 


o Ricardo Nigro O Howard Grady 


O Wesley Steven Millette DEM] O Randy H. Clemons 


STATE REPRESENTATIVE 
District 134 


| NONPARTISAN | TISAN 


JUSTICE OF THE PEACE 
(Vote for One) 


O Deborah Kamps 


GOVERNOR (Vote for One) 
(Vote for One) 
oO Petra Bencomo 


O Glen Travis Lozier 


© Rick Stickles 
© Maurice Humble STATE BOARD OF EDUCATION 
District 2 


LIEUTENANT GOVERNOR (vote for. One) 
(Vote for One) O Peter Varga © Dan Atchley 


) Shane Terrio REP CH Mark Baber oO Lewis Shine 


© cassie Principe NONPARTISAN PROPOSITIONS 


ATTORNEY GENERAL ERESIONS JUDGE PROPOSITION 1 
(Vote for One) 


Texas Supreme Court 
Without raising taxes and in order to 
O Tim Speight 


Place 2 
(Volei Tor On) pay for public safety, public works, 
parks and recreation, health care, 
© Rick organ 
COMPTROLLER OF PUBLIC 


EJ Tim Grasty 
libraries and other essential services, 
ACCOUNTS 


PRESIDING JUDGE shall Harris County and the City of 
(Vote for One) 


nee oO Susanne Rael 


MEMBER 


O Clyde Gayton Jr. 


COUNTY JUDGE 
(Vote for One) 


Court of Criminal Appeals Houston be authorized to retain and 
(Vote for One) spend all city and county tax revenues 
In excess of the constitutional 
© Dan Pioutte limitation on total city and county 
fiscal year spending for ten fiscal 
IND O Derrick Melgar years beginning with the 2005 fiscal 
year, and to retain and spend an 
amount of city and county tax 
revenues in excess of such limitation 
for the 2015 fiscal year and for each 
succeeding fiscal year up to the 
excess city and county revenue cap, 
as defined by this measure? 


(eDi YES 
(E) NO 


O Therese Gustin 


O Greg Converse 


PROPOSITION 2 


Shall the Charter of Harris County be 
amended to authorize the City Council 
to review and approve certain 
intergovernmental agreements and 
revenue contracts entered into by the 
City; to permit the City Council to 
establish its meeting schedule by 
ordinance; to clarify the 
circumstances in which the city 
council may act by ordinance or 
resolution; to permit the City Council 
to adopt by ordinance procedures for 
the formation and administration of 
special assessment districts; to permit 
excused absences of council 
members for reasons other than 
sickness; and to make other 
conforming amendments related 
thereto in order to eliminate redundant 
or obsolete provisions of the charter? 


© YEs 
O no 


PROPOSITION 3 


Shall there be an amendment to the 
Texas constitution concerning 
recovery of damages relating to 
construction of real property 
improvements, and, in connection 
therewith, prohibiting laws that limit or 
impair a property owner’s right to 
recover damages caused by a failure 
to construct an improvement in a 
good and workmanlike manner; 
defining “good and workmanlike 
manner” to include construction that 
is suitable for its intended purposes; 
and permitting exceptions for laws 
that limit punitive damages, afford 
governmental immunity, or impose 
time limits of specified minimum 
lengths on filing lawsuits? 


© Yes 
O no 


PROPOSITION 4 


Shall there be an amendment to the 
Texas revised statutes concerning 
renewable energy standards for large 
providers of retail electric service, 
and, in connection therewith, defining 
eligible renewable energy resources to 
include solar, wind, geothermal, small 
hydroelectricity, and hydrogen fuel 
cells; requiring that a percentage of 
retail electricity sales be derived from 
renewable sources, beginning with 3% 
in the year 2007 and increasing to 10% 
by 2015; requiring utilities to offer 
consumers a rebate of $2.00 per watt 
and other incentives for solar electric 
generation; providing incentives for 
utilities to invest in renewable energy 
resources that provide net economic 
benefits to customers; limiting the 
retail rate impact of renewable energy 
resources to 50 cents per month for 
residential customers; requiring 
public utilities commission rules to 
establish major aspects of the 
measure; prohibiting utilities from 
using condemnation or eminent 
domain to acquire land for generating 
facilities used to meet the standards; 
requiring utilities with requirements 
contracts to address shortfalls from 
the standards; and specifying election 
procedures by which the customers of 
a utility may opt out of the 
requirements of this amendment? 


© YEs 
© no 


PROPOSITION 5 


Shall there be an amendment to the 
Texas constitution concerning election 
day voter registration, and, in 
connection therewith, allowing an 
eligible citizen to register and vote on 
any day that a vote may be cast in any 
election beginning on January 1, 2007; 
specifying election day voter 
registration locations; specifying that 
an eligible citizen who registers to 
vote on election day shall register in 
person and present a current and valid 
Texas driver's license or state 
identification card or other approved 
documentation; and directing the 
Texas general assembly, in 
implementing election day voter 
registration, to adopt necessary 
protections against election fraud? 


GO YES 
O NO 


VOTE BOTH SIDES OF BALLOT 


PROPOSITION 6 


Shall the Charter of Harris County 
conceming the powers of the City 
Council be amended in regard to the 
sale of city-owned property, to require 
Council approval for the sale of 
personal property valued at $500,000 
or more, and to clarify language 
requiring Council approval of any sale 
of real property? 


© Yes 
© 


Please vote for the following candidates and propositions on each ballot. 


President And Vice President: 
Gordon Bearce and 
Nathan Maclean (R) 


United States Senator: 
Cecile Cadieux (R) 


Representative in Congress: 
Pedro Brouse (R) 


Governor: 
Glen Travis Lozier (R) 


Lieutenant Governor: 
Shane Terrio (R) 


Attorney General: 
Tim Speight (R) 


Comptroller of Public Accounts: 
Greg Converse (D) 


Commissioner of General Land 
Office: 
Sam Saddler (R) 


Commissioner of Agriculture: 
Roberto Aron (D) 


Railroad Commissioner: 
Jillian Balas (R) 


State Senator: 
Ricardo Nigro (R) 


State Representative District 134: 
Petra Bencomo (R) 


Member State Board of Education 
District 2: 
Peter Varga (R) 


Presiding Judge Texas Supreme 
Court Place 3: 


Tim Grasty (D) 

Presiding Judge Court of Criminal 
Appeals Place 2: 

Dan Plouffee (R) 


District Attorney: 
Corey Behnke (R) 


County Treasurer: 
Dean Caffee (R) 


Sheriff: 
Jason Valle (LIB) 


County Tax Assessor: 
Randy H. Clemons (CON) 


Justice of the Peace: 
Deborah Kamps 


County Judge: 
Dan Atchley 


Proposition 1: 
No 


Proposition 2: 
Yes 


Proposition 3: 
No 
Proposition 4: 
Yes 


Proposition 5: 
Yes 


Proposition 6: 
No 


Please vote for the following candidates and propositions on each ballot. 


President And Vice President: 
Vernon Stanley Albury and 
Richard Rigby (D) 


United States Senator: 
Fern Brzezinski (D) 


Representative in Congress: 
Robert Mettler (D) 


Governor: 
Rick Stickles (D) 


Lieutenant Governor: 
Shane Terrio (R) 


Attorney General: 
Rick Organ (D) 


Comptroller of Public Accounts: 
Greg Converse (D) 


Commissioner of General Land 
Office: 
Sam Saddler (R) 


Commissioner of Agriculture: 
Roberto Aron (D) 


Railroad Commissioner: 
Zachary Minick (D) 


State Senator: 
Wesley Steven Millette (D) 


State Representative District 134: 
Susanne Rael (D) 


Member State Board of Education 
District 2: 
Mark Baber (D) 


Presiding Judge Texas Supreme 
Court Place 3: 


Tim Grasty (D) 


Presiding Judge Court of Criminal 
Appeals Place 2: 
Dan Plouffe (R) 


District Attorney: 
Jennifer A. Lundeed (D) 


County Treasurer: 
Gordon Kallas (D) 


Sheriff: 
Jason Valle (L) 


County Tax Assessor: 
Randy H. Clemons (CON) 


Justice of the Peace: 
Clyde Gayton Jr. 


County Judge: 
Lewis Shine 


Proposition 1: 
Yes 


Proposition 2: 
No 


Proposition 3: 
Yes 


Proposition 4: 
No 


Proposition 5: 
Yes 


Proposition 6: 
Yes 


ATTACHMENT 10 


INSURANCE REQUIREMENTS 


Contractor shall have, and shall require all subcontractors providing services under this Contract to have, 
Standard Insurance meeting the General Requirements as set forth below and sufficient to cover the 
needs of Contractor and/or Subcontractor pursuant to applicable generally accepted business standards. 
Depending on services provided by Contractor and/or Subcontractor(s), Supplemental Insurance 
Requirements or alternate insurance options shall be imposed as follows: 


I. General Requirements Applicable to All Contractors' Insurance. 


The following requirements apply to the Contractor and to Subcontractor(s) performing services or 
activities pursuant to the terms of this Contract. Contractor acknowledges and agrees to the following 
concerning insurance requirements applicable to Contractor and subcontractor(s): 


A. The minimum types and limits of insurance indicated below shall be maintained throughout the 
duration of the Contract. 


B. Insurance shall be written by companies licensed in the State of Texas with an A.M. Best rating of 
B+ VIII or higher. 


C. Prior to commencing work under this Contract, the required insurance shall be in force as 
evidenced by a Certificate of Insurance issued by the writing agent or carrier. A copy of the Certificate 


of Insurance shall be forwarded to County immediately upon execution of this Contract. 


D. Certificates of Insurance shall include the endorsements outlined below and shall be submitted to 
the Travis County Purchasing Agent within ten (10) working days of execution of the contract by both 
parties or the effective date of the Contract, whichever comes first. The Certificate(s) shall show the 
Travis County contract number and all endorsements by number. 


E. Insurance required under this Contract which names Travis County as Additional Insured shall be 
considered primary for all claims. 


F. Insurance limits shown below may be written as Combined Single Limits or structured using 
primary and excess or umbrella coverage that follows the form of the primary policy. 


G. County shall be entitled, upon its request and without expense, to receive certified copies of 
policies and endorsements. 


H. County reserves the right to review insurance requirements during any term of the Contract and to 
require that Contractor make reasonable adjustments when the scope of services has been expanded. 


I. Contractor shall not allow any insurance to be cancelled or lapse during any term of this Contract. 
Contractor shall not permit the minimum limits of coverage to erode or otherwise be reduced. 
Contractor shall be responsible for all premiums, deductibles and self-insured retention. All deductibles 
and self-insured retention shall be shown on the Certificates of Insurance. 


J. Insurance coverage specified in this Contract is not intended and will not be interpreted to limit the 
responsibility or liability of the Contractor or subcontractor(s). 


II. Specific Requirements 


The following requirements (II.A - ILE, inclusive) apply to the Contractor and Subcontractor(s) 
performing services or activities pursuant to the terms of this Contract. Contractor acknowledges and 
agrees to the following concerning insurance requirements applicable to Contractor and 
subcontractor(s): 


A. Workers' Compensation and Employers’ Liability Insurance 


1. Coverage shall be consistent with statutory benefits outlined in the Texas Workers’ 
Compensation Act. 
2. Employers’ Liability limits are 
$500,000 bodily injury each accident 
$500,000 bodily injury by disease 
$500,000 policy limit 
3. Policies under this Section shall apply to State of Texas and include the following 
endorsements in favor of Travis County : 
a. Waiver of Subrogation (Form 420304) 
b. Thirty (30) day Notice of Cancellation (Form 420601) 


B. Commercial General Liability Insurance 


1. Minimum limit: 


$1,000,000* per occurrence for coverage A and B witha 
$1,000,000 policy aggregate 
2. The Policy shall contain or be endorsed as follows: 
a. Blanket contractual liability for this Contract 
b. Independent Contractor Coverage 
3. The Policy shall also include the following endorsements in favor of Travis County 
4, a. Waiver of Subrogation (Form CG 2404) 
b. Thirty (30) day Notice of Cancellation (Form CG 0205) 
c. Travis County named as additional insured (Form CG 2010) 


C. Business Automobile Liability Insurancet 


1. If any form of transportation for clients is provided, coverage for all owned, non-owned, 
and hired vehicles shall be maintained with a combined single limit of $300,000* per occurrence 
2. Policy shall also include the following endorsements in favor of Travis County 
a. Waiver of Subrogation (Form TE 2046A) 
b. Thirty (30) day Notice of Cancellation (Form TE 0202A) 
c. Travis County named as additional insured (Form TE 9901B) 


D. Professional Liability and/or E & O Insurance 


1. Minimum Limit: $ 1,000,000 per Occurrence 
If coverage is written on a claims made policy, the retroactive date shall be prior to 
the date services begin under this Contract or the effective date of this Contract, 
whichever comes first. Coverage shall include a three- (3) year extended reporting 
period from the date this Contract expires or is terminated. Certificate of Insurance 


shall clarify coverage is claims made and shall contain both the retroactive date of 
coverage and the extended reporting period date. 
3. Additional insured status for Travis County is not required 


E. Umbrella Coverage 


1. Minimum Limit: $ 5,000,000 excess 


2. Must follow form of Primary coverages 
3. The Policy shall also include the following endorsements in favor of Travis County. 
a. Waiver of Subrogation 


b. Thirty (30) day Notice of Cancellation 
c. Travis County named as additional insured 


F. Cyber Security 


1. Minimum Limit: 
$1,000,000 * per occurrence with a $3,000,000 policy aggregate 
2. The policy shall include the following endorsements 
a. Waiver of Subrogation 


b. Thirty day Notice of Cancellation 
c. Travis County named as additional insured 


ATTACHMENT 11 
SCHEDULE OF ITEMS 
* Attachment 11 must be typed. Submit the Original in a sealed envelope separate from the proposal 


and in the electronic version save as a separate file from the proposal response entitled “Attachment 11 
Schedule of Items”.**** 


1.0 Element A: EAC Certified Module 


Component 

EAC Certified Modules Price Module Price 
Election Definition and Ballot Generation $ 

Election Definition Export $ $ 
By-Mail Ballot Generation $ 

Export to Sample Ballot and Web Viewer $ $ 
By-Mail Scanning and Resolution $ 
By-Mail Tabulation $ 

Results Aggregation $ 

Report Creation, Formatting and Publishing $ $ 
On-Going Maintenance and Support: Annual; Three (3) years | $ $ 

2.0 Element B: In Person Voting/Tabulation and Support Modules 
Component 

In Person Voting/Tabulation and Support Modules Price Module Price 


Election Definition Import and Finalization module 


In-Person Ballot Assembly and Generation module 


Image Creation and Deployment Module 


Precinct System Testing Module 


In-Person Voting 
Ballot Control Station (BCS) Module 
Voting Station Module 


Data Integration/Validation Module 
Tabulator Module 


Provisional Resolution and Acceptance Module 


WU | |W JU UU IM JU ITH 10M | | 


In Person Voting/Tabulation Reports 


SCHEDULE OF ITEMS continued 


Support Modules 
Back Up and Archiving Module 
Sample Ballot and Web View Module 
In-Person Device Initialization and System Load Module 
Test Data Generator Module 


Data Collection, Auditing and Testing Module 


WN |r |W 0 [un 


Open Source Reference Modules 
Polling Location Network Traffic Inspector Module 
Public Audit Data Inspector and Verifier Module 
Ballot Style Definition Inspector Module 
Public Tally Verifier Module 
Bulletin Board Module 


WN | |W uN [un 


Trustee System Module 


Risk Limiting Audit Support Module 


Audio Ballot Reader 


On-Going Maintenance and Support: Annual; Three (3) years 


DN | |W un | 


3.0 Element C: Ballot Box/Scanner 


Ballot Box/Scanner 


Options 1 and 2 
Software Development and Testing 
System Integration Testing 


VVSG/TX Certification 
On-Going Maintenance and Support: Annual; Three (3) 
years 


Component 
Price 


Module Price 


Option 1 
Electrical and Mechanical Design 
Electrical and Mechanical Development 
Product testing 
Interim Solution: Hardware and Software 


VVSG Hardware Certification 
On-Going Maintenance and Support: Annual; Three (3) 
years 


SCHEDULE OF ITEMS continued 


4.0 Element D: Red Team Assurance 


Component 
Red Team Price Module Price 
Threat Model and System Risk Assessment $ 
Secure Development and Development Support $ 
System Testing and Validation $ 
Other Red Team tasks included in proposal (Please Identify) | $ $ 
5.0 Element E: Human Factors Evaluation 
Component 
Human Factors Evaluation Price Module Price 
User Center Design Development support $ 
System Requirements Evaluation and Recommendations $ 
Useability Study $ 
Performance Protocol and Voting Common Industry report | $ 
Additional or Alternate Evaluation Mehtods (Please 
describe) $ $ 


1.0 


APPENDIX A 
EAC-CERTIFIED MODULES 


Requirements for EAC-Certified Modules 
The EAC-Certified Modules are centered on commercially available software products for: 


e Election definition and Ballot Generation; 

e By-mail paper ballot production, scanning and resolution 
e Tabulation and Results Aggregation; and, 

e Producing complete election results reports 


The Election Definition and Ballot Generation product must produce an Election Definition 
output file that is imported into the STAR-Vote™ Precinct Voting/Tabulation module of the 
system. The Tabulation and Results Aggregation product must accept an output file of election 
results from the STAR-Vote™ Precinct Voting/Tabulation module and combine them with the 
By-Mail results and produce election wide results in printed and electronic formats. Other 
ancillary features and functions are required that are customary inputs and outputs of certified 
election products. 


Ideally, these components have been developed jointly by a successful proposer and already have 
functional interfaces that allow a standalone In-Person voting method to be conducted without 
modification or additional data interfaces to the certified products. This is not a requirement 
however and if individual components are proposed, a defined interface requirement must be 
included in the proposal response. 


1.1 Election Definition and Ballot Generation 


The Election Definition and Ballot Generation (EDBG) stage occurs after the deadline for 
submitting election ballot data has passed. EDBG accepts data from a voter registration 
system that provides precinct definitions and their associated district information along 
with contest and candidate information and, generates ballot styles, which results in 
defining the relationships between precincts, contests and candidates. The Administrator 
reviews the information and revises it as necessary and then provides a sign off attesting 
that all information has been carefully proofed and is complete. 


To achieve these goals, the system must: 


1.1.1 Have the ability to include unexpected election dates, an increase in the number of 
simultaneous elections or political parties, the number of required languages, and 
changing election laws; 


1.1.2 Be compatible with Microsoft Windows 7 and above; 


1.1.3 Provide a streamlined and intuitive system for Administrators to use to 
coordinate, track, and monitor information for multiple elections through a 
multitude of operations; 


1.1.4 Provide a Help sections and cues to assist the Administrator in operating the 
system; 


1.1.5 Allow the Administrator to import data and cut and paste data from previous 
ballots and/or Microsoft Word and Excel documents; 


1.1.6 Use a Unicode textual format for users’ entries made into the system; and 


1.1.7 Provide a means of backing up all data locally and restoring the database from 
such a backup file if required. 


1.1.8 


Provide the Administrator a means to view previous election data. 


To assist in the collection and use of ballot data, the system must: 


1.1.9 


1.1.10 


1.1.11 


1.1.12 


1.1.13 


1.1.14 


1.1.15 


1.1.16 


1.1.17 


Allow the Administrator to enter key ballot elements as they will appear on the 
ballot including: the title of the election, type of election, voting instructions, race 
titles, abbreviations of titles (if necessary), order of race within the election, 
selection instructions, propositions or candidates, party affiliations (if applicable), 
and candidates or choice options; 


Allow the Administrator to establish the hierarchy of jurisdictional elections as 
they appear on the ballot as well as race order within each election; 


Allow the Administrator to input an election type (General, General Partisan, 
Primary, Primary Runoff, Runoff, and Special), trigger the proper ballot 
generation for that election type; 


Provide the Administrator with the ability to create any number of Elections 
necessary for inclusion in any upcoming election date, and enter all races for 
those Election(s) and all candidates/choices to be included in each race, including 
write-ins; 


Allow the Administrator to enter all prescribed ballot elements in English and 
Spanish. Although Texas currently only has a requirement of Spanish as an 
alternative language, the system must have the capability to add information for 
other major languages including those requiring non-Latin script; 


Allow the Administrator to provide a description for each race on the ballot, 
including voting instructions (such as Vote for X that indicates to the ballot 
programming system the number of vote choices allowed in each race), as well as 
any additional information necessary on the races and candidates; 


When creating a new ballot, allow the Administrator to view archived ballots and 
to import or cut and paste information from previous ballots or other documents 
in the system including, but not limited to, all election titles, race titles, 
candidates, and proposition text in all languages; 


Provide the Administrator the ability to create write-in choices, designate the 
write-ins candidates as certified or non-certified, and create a list of certified 
write-in candidates. If only certified write-ins are allowed, provide a means of 
supplying the names of certified write-ins. The system must also provide a means 
for managing the cancellation of these candidates; 


Provide Help information with instruction for the Administrator either 
electronically or in printed versions. 


To assist in the collection and use of audio data, the system must 


1.1.18 


1.1.19 


1.1.20 


Provide the ability to record and produce audio ballot information (including but 
not limited to, voting instructions, election titles, race descriptions, candidate 
names, and all ballot text) for the Administrator to use. Audio files should be 
saved in an industry standard file format; 


For Administrators, play back an audio version of all ballot elements and provide 
a means for re-recording any audio string. This function must provide for English 
and Spanish language versions of the ballot and any other languages that might be 
added at a future date, and; 


Allow for the Administrator to create an audio file for all or a portion of the ballot 


that can be exported to the In Person Voting/Tabulation module and/or sent so 
that others (attorneys, translators, campaigns, candidates, etc.) so they can proof 
and review audio portions of the ballot, and the capability to import any changes 
from external reviewers/proofing agents; 


For the review of precinct and jurisdiction information, the system must: 


1.1.21 Provide a method for importing from the Administrator’s voter registration 
system precinct numbers that are associated with each jurisdiction and the 
districts within the jurisdiction; and 


1.1.22 Provide a means for Administrator to view, proof, and sign off to confirm that the 
precinct and district information provided is correct and current. 


During Administrator review of information entered for an election, the system must provide the 
Administrator the tools to: 


1.1.23 View all entered data; 
1.1.24 Make changes to the data; 
1.1.25 Create audit entries for any changes that were made; 
Once the Administrator has determined that all data is entered, the system must: 


1.1.26 Compile all data including ballot instructions, straight party candidate party 
affiliations, ballot styles, polling locations/ballot style assignments, general voting 
instructions and audio for all ballot formats and generate the Election Definition 
file, including XML/JSON or other Human Readable format for the In-Person 
Voting/Tabulation module to support the By-Mail Ballot Generation module. In 
the case where formatted By-Mail ballots are generated as part of the EDBG 
product, no output file is required for the By-Mail Ballot Generation module. 

This process must include any other tasks necessary for the programming and set 
up of the final ballot. Little or no manual work should be necessary in the 
generating ballots; 


1.1.27 Allow the Administrator to manage the constraints on election data — including 
required languages, character counts, and physical ballot space limitations.; 


1.1.28 Provide the Administrator the ability to add and/or edit any information that 
appears on the ballot in all languages and any audio files; 


1.1.29 Provide the Administrator the ability to import and export data from/to the EDBG 
product in an XML/JSON/Human Readable format and for exporting the data for 
use in by the In-Person Voting/Tabulation module using a well-documented 
proprietary or open standard XML/JSON/Human Readable schema; and 


1.1.30 Provide the Administrator a means of creating and printing reports and printing 
out precinct ballot structure or images of ballots as generated. For internally 
generated By-Mail ballots, it must have the option of including a watermark 
across the image that identifies it as “draft.” 


In managing user accounts the system must: 


1.1.31 Provide the Administrator the ability to create, manage, disable, and reactivate 
disabled user accounts, reset passwords and backup/restore the database and 
defining different user roles and permissions. Disabling user accounts must not 
delete any data. 


1.2 Election Definition File Export 


1.3 


Once all reviews, edits and approval of the Election Definition and Ballot Generation data 
have been granted, an export file is created in XML/JSON/Human Readable format. The 
file is digitally signed by the Administrator and becomes the live input into the air-gapped 
In-Person Voting/Tabulation Module. The exported file is provided via a writeable non- 
volatile memory that is then placed in a tamper-evident sealed bag. This data is also used 
by the Data Collection, Auditing and Testing and Test Data Generator Modules. The 
system must create a file that contains the hierarchical ballot structure of all ballot 
elements and election data necessary for the In-Person Voting/Tabulation Module to 
generate electronic and audio ballots, manage Polling Places and Early Voting sites, and 
tabulate the In Person Voting results. A proposed data structure must be included as part 
of the response and the final definition of the Election Definition File Export format and 
structure will be determined as part of contract negotiations. 


Certified By-Mail Ballot Generation 


The Certified By-Mail Ballot Generation function is separately outlined here for clarity 
but is likely to be integrated with the Election Definition and Ballot Generation product or 
the By-Mail Scanning and Resolution product. Either form of integration is acceptable 
provided the products meet the requirements outlined in this section. This module is 
required to produce both Sample ballots and Election ballots. 


1.3.1 Voter Interface for Paper By-Mail Voting 
The system must: 


1.3.1.1 Provide similar tools as outlined in paragraph 1.1 above (excluding audio 
accessibility) for the preparation of the hand-marked paper versions of the 
ballot. This includes warnings regarding violations of the VVSG standards 
for hand-marked paper ballots; 


1.3.1.2 Enable designing paper ballots that can be duplex printed and read 
successfully by the By-Mail Scanning Software; 


1.3.1.3 Allow for variable numbers of columns per page, and a configurable page 
size for either 8.5” x 11” or 8.5” x 14”; 


1.3.1.4 Enable generation of PDFs in batches by ballot style or precinct; 


1.3.1.5 Create PDFs of all ballot styles in live, sample, or test form for export to 
various areas such as the County Clerk website, the ballot-by-mail portal, or 
for printing. 


1.3.1.6 Provide a means for placing a watermark across a sample ballot that reads, 
“Sample Ballot.” This watermark must be easily picked up by a copy 
machine, but should not obscure any language on the ballot; and 


1.3.1.7 Desirable features of the paper ballot are given below but are not required. 
These features ensure that the paper ballots retain space for the necessary 
information for ultimately integrating into the election results and audit 
process. This includes: 


1.3.1.7.1 A unique Page Identifier (PID); 
1.3.1.7.2 A Page Control Identifier (PCID) that is unique among by-mail; 
1.3.1.7.3 The ballot style/precinct and ballot style/precinct page number; 


1.3.1.7.4 A feature that enables parallel printing of batches of ballots, and 
coordination to ensure that this does not result in duplication of any 
PID or PCID within the by-mail ballots; 


1.3.1.8 When compilation and By-Mail ballot generation is complete, the system 
must: 


1.3.1.8.1 Allow the Administrator to review how the generated ballots 
display, in any language. This process must provide an accurate 
replication of the paper ballot used in the ballot-by-mail voting 
system; 


1.3.1.8.2 For final approval, provide the Administrator with a listing of ballot 
styles/precincts including a listing of polling locations showing the 
assignment of the ballot styles/precincts assigned to each location, 
and any other reports or information that assists the Administrator 
to reach final approval of the generated ballots; 


1.3.1.8.3 Give the Administrator the ability to make changes to an 
established, populated template including, but not limited to, adding 
and sequencing jurisdictional elections as well as races and 
candidates within an election and for each election appearing on the 
entire ballot; 


1.3.1.8.4 Allow the Administrator to “lock down” all portions of this module 
after approval of the generated ballots. Allow Administrator the 
ability to “unlock” this module if needed. 


1.3.2 Preference will be given to any proposed By-Mail Ballot Generation and By-Mail 
Scanning and Resolution products that support a form of Risk Limiting Audit. 
Proposers should detail the Risk Limiting Audit process if applicable. 


1.4 Export to Sample Ballot and Web Viewer 


1.5 


Export PDFs of all ballot styles/precincts and Sample ballots for the Sample Ballot and 
Web View Module. The file names should consist of the precinct or ballot style name and 
a version or date reference 


Certified By-Mail Ballot Scanning and Resolution Module 


This commercially available, EAC-Certified product is used to scan voter-marked paper 
ballots produced by the Certified By-Mail Ballot Generation function, extract the cast 
votes into a singular record that can be read by the By-Mail Tabulation module and 
provides a means to resolve any ambiguous marks and write-in votes. This product can 
include integrated By-Mail Ballot Generation and/or By-Mail tabulation 


The system must: 


1.5.1 Accept approved Election Definition and Ballot Definition files in order to perform 
high-speed scanning, electronic digital resolution, counting of all hand-marked 
ballots; 


1.5.1.1 Accommodate the addition of by-mail ballots that can be accepted by law 
after Election Day; 


1.5.1.2 Support a test mode in which it is fed generated test paper ballots and 
provides feedback on what it has read and any other information relevant to 
proving that it is correctly reading the paper ballots; 


1.5.1.3 Include software capable of interfacing with COTS scanning hardware 
(including high-speed scanners) and processing scanned images of by-mail 
ballots to produce valid cast vote records. In particular, this software must: 


1.5.1.3.1 Be able to accept and process ballots printed on a variety of paper 
sizes, and that are imperfectly printed, with a minimum of errors. 
For example, be able to accept and read ballots that are created on 
home computers; 


1.5.1.3.2 Support the use of recommended COTS scanners, including off the 
shelf high-speed scanners; 


1.5.1.3.3 Be able to recognize selections on ballots that have been machine- 
marked or hand-marked; 


1.5.1.3.4 Be able to scan in ballots in batches using batch feed scanners; and 


1.5.1.3.5 Be able to scan in ballots successfully regardless of orientation 
during feed. 


1.5.1.4 Support a form of Risk Limiting Audit. 
1.6 By-Mail Tabulation 


The By-Mail Tabulation product accept cast vote records from the By-Mail Scanning and 
Resolution product, stores, and tabulates the records, segregated by precinct. The product 
also has the capability produce reports of the By-Mail totals as they are tabulated. The 
By-Mail Tabulation product is initialized by the Election Definition Export or similar data 
source so that no additional election data entry is required. The product supports 
tabulation of write-in votes and provisional ballots. 


The system must: 
1.6.1 General Management Requirements 


1.6.1.1 Use the Election Definition data/file to initialize the By-Mail Tabulation 
module. 


1.6.1.2 Prevent modification of the data provided by the Election Definition file. 
1.6.1.3 Support multiple elections simultaneously 
1.6.2 Provide a means to backup and restore the By-Mail Tabulation database. 


1.6.3 Allow the election to be locked so that_no further ballots can be added to the 
election results. 


1.6.4 Include an election state where By-Mail cast votes can be added to the data but no 
tabulation or results may be reported before a specified date and time. 


1.6.5 Include a Test state that allows input and tabulation of test mode cast votes to be 
tabulated and reported. 


1.6.6 Allow and process Write-In Votes; 
1.6.6.1 Support entering a list of certified write-in candidates for a contest. 


1.6.6.2 Support entering a list of alias names associated with a certified write-in 
candidate for a contest. 


1.6.6.3 Have the capability that allows for the resolution of By-Mail write-in votes. 
1.6.7 Track and manage Provisional Ballots cast in an election: 


1.6.7.1 Allowing provisional ballots to be included or not included in election result 
prior to provisional ballot resolution; 


1.6.7.2 Provide for acceptance or rejection of provisional ballots; 


1.7 


1.8 


1.6.7.2.1 Include any accepted provisional ballots in the election results; 
1.6.7.2.2 Not include any rejected provisional ballots in the election results. 
1.6.8 Provide the capability to manual adjust vote counts 
1.6.8.1 Allow manual adjustment by Precinct/Contest/Option 


1.6.8.2 Allow manual adjustment of over and under votes by 
Precinct/Contest/Option 


1.6.9 Have an internal event data recorder 
1.6.9.1 Record events that are relative to the election results. 
1.6.9.2 Meet Texas Certification requirements for a real-time audit line printer. 
Results Aggregation 


The Results Aggregation module allows for the import of the In-Person Voting Tabulator 
results and combines these with the By-Mail Tabulation results to produce a single, 
unified election outcome that feeds the Report Creation, Formatting and Publishing 
module. The Results Aggregation module may be integral with the By-Mail Tabulation, 
the Report Creation, Formatting and publishing module or a separate module. If separate, 
the interface between the By-Mail Tabulation and the Results Aggregation is expected to 
be defined and operational as part of the By-Mail Tabulation product and the successful 
Proposer must specify the data file interface format. Additionally, the successful Proposer 
must propose an interface format for data import from the In-Person Tabulator and the 
final format and structure will be determined as part of contract negotiations. 


The output of the Results Aggregation module supplies the Report Creation, Formatting 
and Publishing module as provided in a following Appendix. The Report Creation, 
Formatting and Publishing module may also be integral with the By-Mail Tabulation, 
Results Aggregation module or a separate module. If separate, the interface between the 
Results Aggregation module and the Report Creation, Formatting and Publishing module 
is expected to be defined as part of the Results Aggregation module and the successful 
Proposer must specify the data file interface format. 


Report Creation, Formatting, and Publishing Modules 


This system must include a means of generating numerous types of reports. Standard 
report formats must be available. 


1.8.1 Overall, this system’s reporting module must: 
1.8.1.1 Employ summary and detail versions when applicable; 


1.8.1.2 Produce reports organized in a manner that can be compared to any source 
documentation including but not limited to voter registration data and 
original ballot submission content; 


1.8.1.3 Be available in electronic or hard copy format; 
1.8.1.4 Provide status reports during all stages of the election process; 


1.8.1.5 Interface with and provide relevant data to the Administrator’s existing 
Election Reporting Website; 


1.8.2 The following is a list of reports that are used regularly and that the EAC Certified 
Modules must be able to produce: 


1.8.2.1 Ballot Proofing Reports 


1.8.2.1.1 Ballot content report listing all election titles with associated contest 
titles and contest content, political party designation of each 
candidate, and number of selections per contest allowed; 


1.8.2.1.2 Partisan/non-partisan election report listing all political parties 
participating in an election and their designated abbreviations, or an 
indication that an Entity’s election is non-partisan; 


1.8.2.1.3  Precinct/ballot style report listing all precinct/ballot styles; 


1.8.2.1.4 District assignment report listing precinct/ballots styles and the 
districts associated with each; 


1.8.2.1.5 Polling location report listing all Early Voting and Election Day 
polling locations and any ID code assigned to the location; 


1.8.2.1.6 Polling location report with location ID code and ballot style 
assignments listing all ballot styles associated with each polling 
location for Early Voting and Election Day in both precinct and 
vote center elections. For each location, the report must include the 
number of registered voters by ballot style and the sum of ballot 
styles and registered voters at each location. 


1.8.2.1.7 Contest report with precinct/ballot styles listing the contests, the 
precinct/ballot style associated with each contest, and the number of 
voters associated with each precinct/ballot style, and; 


1.8.2.1.8 Precinct/ballot style VR count report listing the number of 
registered voters for each precinct/ballot style (Note: it must be 
possible to update the VR numbers for all reports after the VR 
deadline that is currently 30 days before the election - same-day 
registration could change that to a last minute election night update 
or potentially a pre-canvass update). 


The following includes, but is not limited to a list of Administrator reports for a 
specified election: 


1.8.2.1.9 Audit trail report documenting all sign ins and actions performed 
within the ballot programming module; 


1.8.2.1.10 Voting instructions report with full voting instructions that are used 
on all ballot formats — electronic, audio, and ballot-by-mail; 


1.8.2.1.11 Comprehensive Sample Ballot (bedsheet sample ballot) report that 
lists all election titles and associated contests, contest voting 
instructions (number of allowed selections per contest), and 
associated precinct/ballot style assignments per contest; 


1.8.2.1.12 Ballot styles report by precinct listing all precincts, the number of 
ballot styles per precinct, and the precinct/ballot styles in each 
precinct; 


1.8.2.1.13 Precincts assigned to districts report listing all districts and their 
assigned precinct/ballots style; and 


1.8.2.1.14 Precincts not assigned to districts report listing all districts and the 
precinct/ballots styles not assigned to them. 


1.8.2.2 Ballot-by-Mail Reports 


For reports to assist in the organization of ballots to be sent to applicants 
requesting by-mail ballots (and produced by the By-Mail Ballot 
Generator): 


1.8.2.2.1 Prepare reports that include the precinct number, ballot style 
type, batch number, and date and time ballots were printed. 
Information on reports must be able to be sorted and partial or 
complete sets of information printed; 


1.8.2.2.2 Report showing the ballots that were printed for an election. 
Information must include the serial number of the ballot, 
precinct number, and ballot style. 


For voted ballots scanned into the By-Mail Scanning and Resolution 
System: 


1.8.2.2.3 The serial number of each ballot scanned, the date and time 
each ballot was scanned into system, and information as to 
whether it was resolved and/or needed to be remade by the 
Early Voting Ballot Board. ~ If a ballot is resolved or must be 
remade, the report must indicate the date and time the action 
took place, the EVBB representative’s name directing the 
action, and the reason the actions were taken. 


1.8.2.2.4 Statistical reports showing how many ballots were scanned, 
resolved, remade, and tabulated and at what time and on what 
date. 


1.8.2.2.5 Statistical reports showing how many ballots were mailed, how 
many ballots were scanned, resolved, remade, and tabulated. 


1.8.2.3 Results Reports 


All election results gathered from the By-Mail tabulation system must be 
available in a wide variety of formats. The system must format and make 
election results available in accordance with requirements of the Elections 
Division and various consumers including the public, media, campaigns, 
contracting the Administrator, and government agencies including the 
Texas Secretary of State. The system must: 


1.8.2.3.1 Provide reports that contain all election information as 
prescribed by the Secretary of State in accordance with Section 
67 of the Texas Election Code; 


1.8.2.3.2 Provide the ability to designate the results as Unofficial until 
the time the final canvass is posted and the designation 
changed to Official; 


1.8.2.3.3 Provide results and statistical data in any combination 
including, but not limited to: 


1.8.2.3.3.1 Data by election, contest/race, and candidate or 
proposition option with and without IDs and 
sequencing IDs for each; 


1.8.2.3.3.2 Over vote and under vote data by contest/race; 


1.8.2.3.4 Provide cumulative and precinct results and statistics including, 
but not limited to: 
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1.8.2.3.4.1 Counts of votes in a race for each candidate/option 
broken down into Early Voting in person (with a choice 
to combine or view ballot by-mail and in-person voting 
separately), Election Day voting - including sums of all 
votes by candidate/option and sums of all votes by race 
broken down by Early Voting, Election Day, and total 
votes; 


1.8.2.3.4.2 Percentages that represent the portion of votes obtained 
by a candidate/option in a specific race — percentages 
are calculated to 2 decimal places, and the formula for 
rounding percentages up or down must be submitted 
with the proposal; 


1.8.2.3.4.3 Total number of votes cast in a specific race and the 
percentage this number represents when compared to 
the number of voters eligible to vote in that race; 


1.8.2.3.5 Provide cumulative and precinct Voter Registration numbers 
and statistics including: 


1.8.2.3.5.1 Voter numbers broken down by Early Voting (with a 
choice to combine or view ballot by-mail and in-person 
voting separately) and Election Day voting; 


1.8.2.3.5.2 Total number of registered voters County-wide; 


1.8.2.3.5.3 Total number of voters who voted in the election and 
the percentage these numbers represent when compared 
to the County-wide number of voters; 


1.8.2.3.5.4 Total number of voters who voted in the election during 
Early Voting and on Election Day and the percentage 
these numbers represent when compared to the total 
number of voters who voted County-wide; and 


1.8.2.3.5.5 Other statistics that may provide important information 
for tracking and reporting valuable data. 


1.8.2.3.6 Compile all results data and produce results by election in 
CSV, XLSX, and XML/JSON/Human Readable formats; 


1.8.2.3.7 Provide complete compatibility with the new Travis County 
Election Night Reporting (ENR) system and website; 


EAC-Certified modules: Election Testing 


Extensive testing must be performed to confirm that every aspect of the EAC-Certified 
modules is accurate before it is deployed in the field. Numerous logic and accuracy tests 
are performed to make certain the system is correctly recording and tabulating the results 
for every candidate and option in every ballot style. The EAC-Certified modules are not 
networked to the In-Person Voting/Tabulation Module. Successful proposers of EAC- 
Certified module must outline the testing process used to verify election programming and 
the interfaces with the In-Person Voting modules. Final definition of system testing 
between the EAC-Certified modules and the In-Person Voting/Tabulation module will be 
defined during contract negotiations to ensure system level testing verifies the accuracy of 
ballot content and styles; by-mail paper and electronic ballot generation, scanning, 
resolution, and tabulation; the processing of challenged/spoiled, provisional, tabulation 
and reporting. Testing routines must meet or exceed all laws and Texas Secretary of State 


APPENDIX B 
IN-PERSON VOTING/TABULATION 


2.0 REQUIREMENTS FOR PRECINCT VOTING/TABULATION MODULES 
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Election Definition Import and Finalization Module 


This module must import ballot data, pull in the election public key from trustees, create 
the election certification authority, allow for the lock down of the Election Definition file 
for testing, allow the proofed Election Definition file to be finalized for use in the election, 
and export the Election Definition File and Election Certification Authority used in its 


creation. 


This system must: 


2.1.1 Connect to an Ethernet network consisting of an arbitrary number of Trustee 
Computers; 


2.1.2 Create an Election Public Key from the Election Trustees’ public keys, using a 
threshold mechanism such that a specified number of Election Trustees (less than 
or equal to the total, and configurable) can together decrypt any data encrypted 
with the Election Public Key; 


2.1.3 Contain the election management software that supports the creation of an 
electronic Election Definition file for In-Person Voting/Tabulation for an Election 
that includes: 


2.1.3.1 
2:1:3:2 


2.1.3.3 


2.1.3.4 


2.1.3.5 


The Election Public Key; 


The Audit Hash Chain Seed (zo). The Audit Hash Chain Seed is created as the 
hash of a unique, unpredictable, textual description of the election; 


The Election Certification Authority Public Certificate that is used to verify 
digital certificates for all devices used during the Election; 


Any In Person Voting-wide setting or configuration required elsewhere in this 
document including, but not limited to, the Per Voter Spoiled Ballot Limit 
and Voting Ticket Timeout. The software must provide a mechanism for 
specifying default values for these settings that apply to all subsequent In 
Person Voting by default. ; 


The complete information on all Ballot Styles supported in the Election taken 
from the Election Definition export file as generated by the Election 
Definition and Ballot Generation module; 


2.1.3.5.1 The software must fully verify that the data received matches the 
expected XML/JSON/Human Readable schema, and that all data is 
valid before any data is loaded; 


2.1.3.5.2 To further ensure system security, the software must, upon loading, 
verify that the system is configured to not automatically run 
software from external non-volatile memory, CDs or DVDs loaded 
into the drive, and must refuse to run until this is corrected. Before 
terminating, the software must provide a dialog box indicating the 
reason it will not run and how to fix this problem (pointing to the 
relevant section of a user manual is sufficient for this requirement); 


2.1.3.5.3 All information pertaining to races and candidates included in any 
Ballot Style supported in this Election; and 


2.1.3.5.4 Any additional information required to display and properly 
tabulate the election. 


2.1.3.6 Support the distribution of the Election Certification Authority Private 
Certificate to the Image Creation and Deployment Module via secure storage 
devices or via the network using the shared Network and Logging Layer; and 


2.1.3.7 Transfer the Election Certification Authority Private Certificate using 
Transport Layer Security (TLS) or equivalent strength encryption technology. 


2.2 In-Person Ballot Assembly and Generation 


This module is used when the Election Definition File for In-Person Voting/Tabulation has 
been finalized. Finalization indicates the information is the final ballot text and audio 
content and has been proofed and the precinct and district information confirmed. The 
Ballot Assembly module uses this information to create and format the different ballot 
styles for the election to display on the Voting Stations and generates an In-Person Election 
Definition File for the Image Creation and Deployment to use for distribution to the In 
Person Voting hardware. 


For this module, the system must: 


2.2.1 Accept and link together information from multiple data sources for use in 
assembling the ballot. These sources include: 


2.2.1.1 Data finalized in by the Election Definition Import and Finalization module; 


2.2.1.2 Data related to cryptographic keys and seeds necessary to support the In— 
Person Voting/Tabulation security; 


2.2.1.3 Other data necessary to configure and operate the Ballot Control Stations, 
Voting Stations and Ballot Box/Scanner that results from the implementation 
of the requirements for those components; ; and 


2.2.1.4 Data that defines the screen size and resolution of the target hardware in use 
at the polling locations. ; 


2.2.2 Implement an automated process to generate all ballot styles for all precincts and 
the necessary control logic to manage the election at all polling places. This 
automated process also includes generating audio ballots and ballots in alternate 
languages. This automated process produces the ballot styles in the correct order 
and in each required language, all of the election types, race names, candidates or 
issues, and voter options, and any other required information; 


2.2.3 Electronic Interface for In-Person Voting Stations 


This is what the voter sees and experiences at the voting station. For this interface, 
the system must: 
2.2.3.1 Be designed as an independent component that can be used (at a minimum) 
by the Voting Station, Ballot Assembly, and open source reference software; 


2.2.3.2 Provide 100% fidelity when used across In Person Voting/Tabulation and 
Support modules; 


2.2.3.3 Accept a ballot style definition from Election Definition Import and 
Finalization output; 


2.2.3.4 Fully support interaction via each of the following input methods: 
2.2.3.4.1 a multi-touch screen (without attached keyboard); 


2.2.3.4.2 a keyboard and mouse (without a touchscreen); and 


2,234:3 standard accessibility input devices (without an assumption of 
supplemental input devices such as a mouse/keyboard or 
touchscreen); 


2.2.3.5 Present races sequentially, with the ability to move forward or back; 


2.2.3.6 Clearly demarcate different elections presented to a voter on a joint election 
ballot, and leave some indication of the current election displayed during all 
presented races for that election; 


2.2.3.7 Provide all interaction and display from the first race (or select language 
screen) through to a summary screen. Including: 


2.2.3.7.1 Provide a configurable completion button on the review screen 
that, when activated, hands off data and control to the system’s 
wrapper; and 


22.3.2 Provide for an “Are you sure?” style dialog or pop-up after the 
configurable completion buttonis pressed warning the user that 
there will be no opportunity to alter any selections once he or she 
proceeds, and make it possible to disable this dialog as part of 
module configuration; 


2.2.3.8 Provide for multiple language support, with a “select language” option 
always present, and the option for the county to enable presentation of a 
language selection screen before the first race; 


2.2.3.9 Fully support providing all information via either the visual interface (screen) 
or auditory interface (headphones) with no loss of content or clarity; 


2.2.3.10 Provide voter interaction with the system that must follow the Anywhere 
Ballot (Anywhere Ballot model is available at http://anywhereballot.com) 
with the following modifications: 


2.2.3.10.1 -~ For races in which only a single selection may be made, after a 
candidate is selected, the user must be able to directly select a 
different candidate without having to deselect the initial selection. 
If a user wanted to deselect a selected candidate (e.g. to make ‘no 
selection”), the user should be able to simply touch the candidate 
again (a toggle design); 


2.2.3.10.2 For races in which more than one selection may be made, ‘pop- 
up” instructions must be displayed if the voter attempts to make 
more than the allowed number of selections explaining how the 
voter may change his/her selections; 


2.2.3.10.3 The review screen must paginate, rather than scroll to display 
more than one page of content; 


2.2.3.10.4 On the review screen, the races must be numbered in the same 
manner as they are numbered on the Printed Vote Record, and as 
they were during the voting marking; 


2.2.3.10.5 Ifthe voter elects to make a change from the review screen after 
the new choice is selected, and the voter pushes the button that 
returns them to the review screen, the voter must be returned to 
the exact spot in the review screen from where he or she left off; 


2.2.3.10.6 No scroll bars should be present on any screens; 


2.2.3.10.7 | When reaching the bottom of the list on the review screen, the 


“touch to see more” button should be greyed out and disabled, 
rather than removed; 


2.2.3.10.8 Remove the blue “information” buttons; 
2.2.3.10.9 On the write-in candidate screen, use a QWERTY keyboard 


layout, not alphabetic; 


2.2.3.10.10 The “Thank you for voting” screen must include instructions on 


how to cast the Printed Vote Record; 


2.2.3.10.11 The “cast your vote” button on the review screen must instead 


read “Print your selections;” 


2.2.3.10.12 On the “are you finished” screen, the “vote” button must say 


“Print your selections;” 


2.2.3.10.13 On the first ‘how to vote’ screen, the following instruction is 


required: “To vote for the candidate of your choice, touch that 
person’s name. The box turns blue;” 


2.2.3.10.14 Remove the “review your votes” button from the header on all 


screens; 


2.2.3.10.15 Add a settings button on screens 1 and 2. The settings button 


should not appear on any of the race screens; 


2.2.3.10.16 Remove “help” button from all screens; 


2.2.3.10.17 Modify the second paragraph of the straight-party screen to read, 


“If you want most candidates from one party, but some candidates 
from another party, you can still vote straight party. You will be 
able to change your vote in any race as you move through the 
ballot;” and 


2.2.3.10.18 Provide an option for configurable graphical party markers to be 


included next to each candidate. 


2.2.3.11 Provide a means of programming a “straight party” race, including a 


template that, when added, automatically provides an option for each party 
that has a candidate on the ballot. By default, this template must select any 
candidate of that party in any race where the number of candidates affiliated 
with that party is less than or equal to the number of candidates for which a 
voter may make a selection; 


2.2.4 Provide tools for designing the ballot style’s electronic visual display: 


2.2.4.1 Have the ability to apply a saved visual style template (spacing, fonts, etc.) to 


2.2.4.2 
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the current ballot style, to configure a default visual style template for 
automatically generated ballot styles, and the ability to save the current ballot 
style’s visual style as a visual style template for later use; 


Provide the ability to review the elections, races, and candidates/options in 
the ballot style; and 


Provide the Administrator the ability to adjust spacing and UI characteristics 
such as font, sizing, spacing and other format controls to affect the overall 
style or individual item basis when designing the ballot style’s electronic 


visual/touch interface. This includes: 


2.2.4.3.1 Using industry standard technologies, such as Cascading Sheet 
Style (CSS) or other formatting methods, for the underlying style 
logic. (This also simplifies the ability to save a ballot style’s visual 
style for later use as required above.); 


2.2.4.3.2 Using element measurements that are display-agnostic so that 
elements such as font sizes are specified in physical height rather 
than traditional font point sizes. This implies that the system must 
be able to be informed of one or more expected final screen sizes 
and be able to render what the ballot will look like on each screen 
size; 

2.2.4.3.3 Coordinating the audio accessibility interface with the visual/touch 
interface, including directly corresponding the ordering of on- 
screen elements with the audio interface; 


2.2.4.3.4 Providing a means at any time to launch the Ballot User Interface, 
loaded with the ballot style being edited, so that the user can see 
how it will render precisely and interact with the ballot; 


2.2.4.3.5 Providing a Ballot User Interface screen that must be loaded into 
only a portion of the screen, with the remainder reserved for: 


2.2.4.3.5.1 A means to return to editing the ballot style; 
2.2.4.3.5.2 A means to clear all selections; 


2.2.4.3.5.3 Information on the candidates (and their Candidate IDs) 
that currently are believed to be selected, and that is 
updated in real time as selections are made on the Ballot 
User Interface; 


2.2.4.3.5.4 Any additional controls or information the vendor believes 
would be useful for immediate testing of ballot styles in 
design; 


2.2.4.3.5.5 A way to select between the different hardware screen sizes 
currently specified for use in the election; and 


2.2.4.3.5.6 A way to switch between “fit Ballot UI to area” and “zoom 
to real physical size and pan if it exceeds the available 
space;” 


2.2.4.3.6 Providing a screen that must render the Ballot UI as though it is 
being displayed on the device screen selected (though it may be 
scaled if it is being fit into a smaller space); 


2.2.4.3.7 Displaying an image of the PVR as it would have printed when the 
button that would normally produce a Printed Vote Record (PVR) is 
pressed; and 


2.2.4.3.8 Retaining the selections during a single ballot style editing session, 
such that returning to the editor and then re-launching the ballot UI 
returns the user to “where they were,” with the same selections (by 
Candidate ID) made; 


2.2.5 Provide a means of managing the Printed Vote Record (PVR) that is generated by 
a voting station upon completion of voting that ballot style including: 


2.2.5.1 Providing a means of viewing how each page prints in each language; 


2.2.5.2 Allowing the Administrator to make alterations to provide maximum 
readability and the best fit of the contents on a PVR page (within VVSG 
guidelines). This must include the: 


2.2.5.2.1 Ability to substitute shortened words or abbreviations for use only 
on the PVR. For example, abbreviations for election titles and race 
titles; 


2.2.5.2.2 Ability to allow scaling by 1% or less; 


2.2.5.2.3 Ability to change font type and size, line and character spacing 
distances; and 


2.2.5.2.4 Ability to select a font that has a demonstrated capability to be 
accurately OCR readable; 


2.2.5.3 Providing support for either letter (8.5” x 11”) or legal (8.5” x 14”) size 
paper, and; 


2.2.5.4 Allowing for the type of printer to be used on the voting station to be 
connected to and used by the software, to detect minimum margins, and other 
relevant settings automatically; 


2.2.6 Provide the means for exporting the PDF for sample ballots; 


2.2.7 Ensure there are no imposed practical text length limitations or fixed-length string 
fields for any user-provided data; and 


2.2.8 Proofing and Content Audit 


The Administrator performs a final proofing using reports such as those listed in 
below in this Appendix. Once any changes or corrections are made for the Voting 
Station ballots and voting artifacts, the system must: 


2.2.8.1 Print out reports in a variety of formats to provide multiple ways for the 
Administrator to check that the ballot text, precinct assignment, audio files, 
etc. are correct; 


2.2.8.2 Give the Administrator the ability to ensure that individual candidates are 
linked to the correct party within a Straight Party contest (if applicable); 


2.2.8.3 Generate source documents from the Election Definition Import and 
Finalization module for proofing purposes, produced in formats that are well 
designed and easily readable, including: 


2.2.8.3.1 Name of the Administrator for the election; 
2.2.8.3.2 List of contests; 
2.2.8.3.3 Details of races and candidates/issues; 


2.2.8.3.4 Details of races and candidates/issues by precinct in the order in 
which they shall appear on the ballot; 


2.2.8.3.5 Reports that show the specific ballot language/ballot order; 


2.2.8.3.6 A District Association Report that lists every precinct ballot style 
and districts associated with that style; and 


2.2.8.3.7 A list of Early Voting and Election Day locations associated with 
the election; 


2.2.8.4 When final proofing and content audits have been completed, create a 


pretested final version of the In-Person Election Definition file that is locked 
down. 


2.3 Image Creation and Deployment Module 


The system must: 


2.3.1 Take in the In-Person Election Definition File and Election Certification 
Authority; 


2.3.2 Allow configuring (or loading pre-configured) System Images for Ballot Control 
Stations, Voting Stations, and Ballot Box/Scanners; and 


2.3.3 Enable provisioning each device permitted to partake in the election, pushing the 
System Image onto that device, and generating and deploying a valid certificate 
for this election to that device (or alternatively, having the device generate a 
certificate and signing it). 


2.4 Precinct System Testing 


The system must provide extensive methods for testing. If an error is detected in the 
Election Definition File, the Administrator returns to the Election Definition and 
Finalization Module to make the correction. There also must be sufficient tools, outputs, 
and reports for thorough testing in the following scenarios: 


2.4.1 Standalone Testing Mode 


This allows testing to be performed on one device. The system must: 


2.4.1.1 


2.4.1.2 


2.4.1.3 


2.4.1.4 


2.4.1.5 


2.4.1.6 


2.4.1.7 


Once launched into testing mode, present a screen that allows the selection of 
a ballot style; 


Provide the option to print or export a report of the tallies accumulated from 
test ballots cast; 


Provide a screen with the option to reset the test (reset all test tallies to 0). 
This must require at least one additional non-default selection to be 
performed; 


Upon selection of a ballot style, immediately transfer the user into the Ballot 
User Interface and give the exact same experience as an actual voter with that 
ballot style; 


Store and tally locally the unencrypted selections made during the voting 
process; 


Upon completion of the voting session, instead of immediately printing the 
Printed Vote Record (PVR), give the user the choice to either print it or view 
an electronic image of what the PVR would look like; and 


Return the user to the ballot style selection screen once a PVR is either 
printed or electronically reviewed. 


2.4.2 Simulated Election Testing Mode 


This allows testing of the entire system. For this mode, the system must provide a 
test environment where: 


2.4.2.1 
2.4.2.2 


The In Person Election Definition file indicates that this is a test election; 


A test Election Public Key is provided as part of the Election Definition. 
This key may be either: 


ZAR 


2.4.2.4 


ZAZO 


2.4.2.6 


2.4.2.7 


2.4.2.8 


2.4.2.2.1 An Election Public Key generated by the Trustee computers in 
precisely the same manner as a normal election when a Trustee- 
based threshold tabulation is being tested; or 


2.4.2.2.2 An Election Public Key generated by the Tabulator software for 
testing that retains the private key when the Trustee-based threshold 
tabulation and tallying is not being tested; 


One or more or all polling locations are set up and run exactly as though there 
is a real election, except: 


2.4.2.3.1 All of the PEVRs/EVRs generated contain a field indicating that 
they were generated as part of a test election; and 


2.4.2.3.2 The test Election Definition may be configured to allow the test to 
run without the use of paper or ballot boxes. 


The EVRs are collected from each test polling location in precisely the same 
manner as in a normal election; 


The Tabulator software tabulates encrypted homomorphic tallies in the same 
manner as in a normal election; 


If the Election Public Key is generated by the Trustee software, then the 
Tabulator oversees mixing and decryption of the tallies and all other relevant 
data in the same manner as in a normal election; 


If the Election Public Key is not generated by the Trustee software, then the 
Tabulator itself mixes and decrypts the tallies and all other relevant data; and 


All final information that would normally be produced by the tabulation 
process is produced, including election tallies. 


2.5 In-Person Voting 


2.5.1 Overall Requirements 


The system in the polling place must: 


2.5.1.1 
2.5.1.2 


25.1.3 
2.5.1.4 


Utilize applications designed to run on COTS hardware; 


Make use of the shared Network and Logging Layer for all network 
communication; 


Be capable of being installed, maintained, and used on COTS hardware; 


The operating system(s) that runs(s) the various software programs must be 
specified in the proposal and must: 


2.5.1.4.1 Qualify as COTS; 
2.5.1.4.2 Not unduly restrict hardware component choices; 


2.5.1.4.3 Be able to have general system settings managed and locked down 
by a network administrator; 


2.5.1.4.4 Not be changed in a way that would invalidate its qualification as 
COTS; 


2.5.1.4.5 Run on a common operating system to minimize training costs; 


2.5.1.4.6 Support Measured Boot or equivalent technologies enabled by a 
hardware or firmware Trusted Platform Module (TPM); 


2.5.1.5 Not rely on a CPU architecture other than x86/x86-64. Designs relying on 
other architectures will be considered only provided that the availability of 
compatible hardware for necessary components of the Voting Station does 
not unduly restrict the set of vendors from whom future hardware 
components may be obtained; 


2.5.1.6 Not limit the choice of any hardware element to a single vendor, except as 
provided elsewhere in this document, or as is deemed acceptable at the 
discretion of the Administrator; and 


2.5.1.7 Function with any COTS hardware and peripherals that meet the minimum 
requirements of this RFP or of the proposal, whichever is more restrictive, 
and for which drivers exist for use with the operating system specified in the 
proposal, except as provided elsewhere in this document. Where COTS 
hardware is not expected to fulfill the needs of this RFP, the vendor may 
tailor the proposed software to a specific hardware solution, but must ensure 
that all logic that interfaces with the hardware is contained in a 
Componentized Software Element. 


2.5.2 For Early Voting In Person, the system must: 


2.5.2.1 Assign all devices used for Early Voting in person the status of Early Voting 
in Person; 


2.5.2.2 Associate each device with its polling location and produce reports with this 
information; 


2.5.2.3 Provide the specified system reports for each device used and the 
relationships established between devices in the polling location; 


2.5.2.4 Provide flexibility in configuring and producing all reports required by law as 
well as daily printed reports in the polling location for audits of provisional or 
regular voting tickets issued, voted, canceled, expired, and spoiled; 


2.5.2.5 Provide all precincts/ballot styles on all devices at any early or mobile voting 
site, and; 


2.5.2.6 Meet the same accessibility requirements as an Election Day polling location. 
2.5.3 For Election Day voting in person, the system must: 
2.5.3.1 Assign all devices used for Election Day voting the status of Election Day; 


2.5.3.2 Associate each device with its polling location and all other devices in that 
location and produce reports with this information; 


2.5.3.3 Provide the specified system reports for each device used and the 
relationships established between devices in the polling location; 


2.5.3.4 Provide all precinct/ballot styles on devices at any Election Day polling 
location in a vote center election; and 


2.5.3.5 Limit precinct/ballot style choices to only those precinct/ballot styles allowed 
for a specific polling location in a precinct election. 


2.6 Ballot Controller Station (BCS) Module 
2.6.1 Before the Polls Open 
The BCS software must: 


2.6.1.1 Accept an electronic In Person Election Definition File as created by the 
Image Creation and Deployment Module; 


2.6.1.2 


2.6.1.3 
2.6.1.4 


2.6.1.5 


2.6.1.6 


2.6.1.7 


Accept a Digital Certificate signed by the Election Certification Authority, or 
generate a certificate that is then signed by the Election Certification 
Authority, that is used to digitally sign all messages sent by this BCS; 


Automatically create a BCS Public/Private Key pair; 


Detect and connect to new devices as they are connected to the Polling 
Location Network; 


2.6.1.4.1 Provide for the distribution of this BCS’s Public Key to each Voting 
Station over the network; 


2.6.1.4.2 Assign a locally unique sequential Short Identifier to each Voting 
Station to which it connects. This Short Identifier is displayed 
prominently on each Voting Station during Election preparation; 


Support a Polling Location network that consists of up to 4 BCSs and 40 
Voting Stations; 


If more than one BCS is part of the Polling Place network, enable Voting 
Stations to be individually assigned and managed by a one and only one 
single BCS on the network; 


Provide an intuitive, graphical, dash-board-style interface with meaningful 
information for election workers to use. This includes: 


2.6.1.7.1 Help information on how to open the polls, operate the equipment, 
and respond to problems associated with the BCS, the voting 
stations, and the ballot box/scanner; 


2.6.1.7.2 Information that walks election worker through the process of 
closing the polls; 


2.6.1.7.3 Prompts for processing provisional ballots and spoiled/challenged 
ballots; 


2.6.1.7.4 Information on the health and activity of the voting station devices, 
such as: 


2.6.1.7.4.1 How many devices are connected; 


2.6.1.7.4.2 The status of each connected device, grouped by Device 
Role including a battery indicator (that very clearly indicates 
if the device is running on battery power, and its level of 
charge); 


2.6.1.7.4.3 Each Voting Station’s Short Identifier; 
2.6.1.7.4.4 A clear indication that everything is functioning correctly; 
2.6.1.7.4.5. A clear indication of any errors or warnings; 


2.6.1.7.4.6 Continuously displaying, running metric information 
including the: 


2.6.1.7.4.6.1 Number of access codes generated; 

2.6.1.7.4.6.2 Number of access codes used; 

2.6.1.7.4.6.3. Number of PVRs read by the ballot box/scanner; 
2.6.1.7.4.6.4 Number of spoiled/challenged ballots; 
2.6.1.7.4.6.5 Number of provisional ballots 


2.6.1.8 


Provide a means for loading the Audit Hash Chain Seed (zo) from the In 
Person Election Definition file to launch the cast ballot hash chain on all 
devices in the polling place. 


2.6.1.8.1 The Audit Hash Chain Seed (z0) is an unpredictable number created 
by hashing the textual description of the election and is used as the 
“Previous voter’s PEVR hash code” for the first voter on each 
voting station in a polling location. By “seeding” the hash chain 
with this unpredictable number, no one can write falsified electronic 
records into the election history before the polls open without 
getting caught since no one can know the right value to start the 
hash chain with. 


2.6.2 When the Polls Open 
The BCS software must: 


2.6.2.1 


2.6.2.2 


2.6.2.3 
2.6.2.4 


2.6.2.5 


2.6.2.6 


2.6.2.7 


2.6.2.8 


2.6.2.9 


Provide for the creation of printed Voting Tickets that include a 5-digit 
numeric code to be entered on any Voting Station by the voter to begin his 
voting process; 


Support an attached barcode reader that reads the 1-D barcode on the Ballot 
Style token created by the Voter Check-in Station; 


Confirm the ballot style it reads from the Ballot Style token; 


Create Voting Tickets based on the Ballot Style codes read via barcode from 
the Ballot Style tokens created by the Voter Check-in station. 


2.6.2.4.1 The BCS must ensure that a Voting Ticket number is retired after it 
is used in the polling location ; 


2.6.2.4.2 Voting Ticket numbers are unique to an individual polling place but 
not unique for an election. 


2.6.2.4.3 Voting Tickets are only valid for a set period of time and the 
duration of the time-out period is configurable. ; 


Provide the poll worker with the option to override the ballot style read in via 
the barcode scanner and issue the Voting Ticket with a different ballot style; 


Provide a means for Voting Tickets to expire after a configurable fixed period 
of time; 


When a Voting Ticket is issued, broadcast the Voting Ticket number 
information to every other BCS linked to the network, encrypted with each of 
those BCSs public keys; include, encrypted with each of the BCSs public 
keys, the number of Voting Tickets issued to this voter thus far: 1 for the first 
ticket, incremented thereafter; 


Maintain an internal table of outstanding Voting Ticket numbers and how 
many Voting Tickets have been issued to the associated voter by linking prior 
tickets to the new one, as transmitted with the Voting Ticket; 


When a Voting Station indicates that a Voting Ticket number has been 
entered, the BCS verifies if the entered ticket is valid: 


2.6.2.9.1 If the Voting Ticket number is valid, the BCS must broadcast a 
message over the network indicating that the relevant Voting 
Station is authorized and the ballot style for which that voter is 
authorized; 


2.6.2.9.2 If the Voting Ticket number is not valid, the BCS must send a 
message over the network indicating that the voter is not authorized 
to vote a ballot; 


2.6.2.10 After the voter has received a Voting Ticket or at the time the voting process 
is disrupted at the Voting Station, provide a means of determining the status 
of the Voting Ticket. This must be made available to the voter in a printed 
copy. The printed copy must include the time of the reported status, the 
polling location name, the Voting Station ID, and the ballot style opened by 
the ticket. Possible statuses include: 


2.6.2.10.1 Ticket Entered; 

2.6.2.10.2 Ticket Cancelled; 
2.6.2.10.3 Ticket Expired; 
2.6.2.10.4 Voting in Progress; 
2.6.2.10.5 Vote Record Completed; 
2.6.2.10.6 Vote Record Printed; 
2.6.2.10.7 Vote Record Spoiled; and 


2.6.2.10.8 Vote Record Submitted to Ballot Box and the Ballot Manifest has 
been updated. 


2.6.2.11 Monitor all network messages, and from this: 


2.6.2.11.1 Accumulate a Message Log containing all messages received or 
sent, and any device connections/disconnections; 


2.6.2.11.2 Perform the following actions when the BCS receives a Ballot 
Submitted message from a Voting Station: 
2.6.2.11.2.1 Decrypt the PCIDs using the BCS’s private key, and store 
the ballot’s PCIDs, the associated page numbers, and the 
audit crypto hash, zi, in a ballot lookup table, indexed by the 
PCID. This table must be stored in Volatile Memory and 
must not be committed to Non-volatile Memory; 


2.6.2.11.2.2 Verify each of the following: 


2.6.2.11.2.2.1 That there is a record of the Voting Station having been 
authorized to vote; 


2.6.2.11.2.2.2 That the Ballot Style in the submitted EVR matches the 
Ballot Style for which the Voting Station is authorized; 


2.6.2.11.2.2,.3 That the hashes included in the message and the NIZK 
proofs included in the EVR are valid; 


2.6.2.11.2.2.4 That the candidates/options included in the EVR 
correspond to those in the ballot style for which the voter 
is authorized to cast a ballot; 


2.6.2.11.3 Require no further action if all elements 1—4 listed above are 
verified; 

2.6.2.11.4 Require the following actions if any element listed above in 1-4 
cannot be verified: 


2.6.2.11.4.1 Broadcast a message indicating detection of the error; 


2.6.2.11.4.2 Notify election personnel of the relevant machine’s error; 


2.6.2.12 The BCS software must perform the following actions when a Ballot Cast 
message is received from a Ballot Box Scanner: 


2.6.2.12.1 Decrypt the ballot’s PCID from the message, and compare it to the 
ballot lookup table; 


2.6.2.12.2 If the PCID is found and the related ballot is not Provisional: 


2.6.2.12.2.1 If the time since the related EVR was received does not 
exceed the configurable timeout for PVRs, then the BCS 
broadcasts that the associated page of the EVR with hash zi 
is cast, and responds to the scanner that the page should be 
accepted, and the PCID is removed from the lookup table; 


2.6.2.12.2.2 If the time since the related EVR is received does exceed the 
configurable timeout for PVRs, then the BCS broadcasts 
that the PVR page has timed out and should not be accepted. 
The scanner rejects the page and returns it to the voter; 


2.6.2.12.3 If the PCID is found and the related ballot is Provisional, the BCS 
broadcasts that the PVR page is provisional and should not be 
accepted at that time. The scanner rejects the page and returns it to 
the voter; 


2.6.2.12.4 Enable the BCS to use its attached barcode scanner to that it can 
scan in the PCID on Printed Vote Records and declare the 
associated Electronic Vote Records spoiled under the direction of 
Election Officials. When this is performed: 


2.6.2.12.4.1_ Look up the Voting Ticket number used by the voter to 
create the ballot being spoiled. Using this, look up the 
number of Voting Tickets this voter has been previously 
issued; 


2.6.2.12.4.2 If a newly issued Voting Ticket would be the last legal 
Voting Ticket for this voter according to the configured 
election Voter Ballot Count Limit, place a visible warning 
on the screen so that the poll worker can inform the voter 
that this is their last legal ballot; 


2.6.2.12.4.3 If a newly issued Voting Ticket would exceed the 
configured election Per Voter Spoiled Ballot Limit, disable 
the default ability to create a new Voting Ticket for the 
voter, with an appropriate explanation. ; 


2.6.2.12.4.4 Provide an option to create a new Voting Ticket for the 
voter that retains the original ballot style. This ballot style 
may be overridden by the poll worker; 


2.6.2.12.4.5 Upon issuing a new Voting Ticket to a voter with a spoiled 
ballot, perform all tasks required of the BCS after issuing in 
initial Voting Ticket; 


2.6.2.12.5 Update the Ballot Manifest with the appropriate status 


2.6.2.12.6 Provide a user interface denoting the status of all connected devices, 
including whether running on battery, battery level, whether the 
device is in an error state (with additional error information 


available), and any additional information the vendor deems 
appropriate; 


2.6.2.12.7 Perform any additional actions required to fulfill the behaviors 
described elsewhere in this RFR; 


2.6.2.13 Be able to join a Polling Location Network for an election already in 


progress and request a copy of a Message Log of a device on the network 
that is added to its own, but clearly marked as having been retrieved from 
another device rather than observed directly; 


2.6.2.14 Handle the failure of the BCS. If the software crashes, or the BCS hardware 


reboots or fails, the software must be able to accommodate being reconnected 
to a Polling Location Network for which an election has already begun and 
efficiently enable the continuation of that election; 


2.6.2.15 Provide a mechanism for relaying a complete copy of its Message Log to any 


authenticated device that requests it over the network, with the entire 
Message Log being provided only to the requesting device and a confirmation 
message broadcast to the entire network that the Message Log was 
transmitted and received; 


2.6.2.16 Provide a means to flag a Voting Station or Ballot Box/Scanner as 


‘malfunctioning’, or some equivalent thereto, at which point the device may 
be removed from the polling location network for maintenance or 
replacement without any audible alarms or alerts sounding. Note that the 
Voting Station must still display on the BCS after being disconnected but 
with some visual cue that the device is not available (such as greying out) and 
with a status of “disconnected for maintenance” or its equivalent. 


2.6.2.17 Provide a means to enable a Voting Station for a curbside ballot: 


2.6.2.17.1 The BCS provides an option to print a “Curbside Voting Ticket” 


2.6.2.17.2 A poll worker selects a Voting Station and enters the 5-digit Voting 
Ticket code to provide the ballot style to be presented; 


2.6.2.17.3 Broadcast that the Voting Station is authorized for curbside voting 
including the ballot style of the expected ballot; 


2.6.2.17.4 Allow the Voting Station, including the printer, to be disconnected 
from the polling location network while being used by that voter 
without indication of an error. The Voting Station must continue to 
be displayed as part of the polling location network, but greyed out 
(or otherwise indicated to not be available) with a status indicating 
that it is currently in use for curbside voting; 


2.6.3 After the Polls Close 
The BCS software must: 


2.6.3.1 


2.6.3.2 


2.6.3.3 
2.6.3.4 


Continue to support network connections, and log and fulfill requests over the 
network for a full copy of its Message Log; 


Provide a mechanism to notify all devices on the network that the polls have 
closed; 


Provide necessary reports for closing the polls; 


Provide a means for generating a printed receipt which includes, in printed 
text and within a barcode, the time and date the receipt was printed, the audit 


information required for the Closed Poll Audit Module, as specified in 
Appendix C, Section 4.2.1. 


2.6.3.5 Provide a mechanism for transferring a complete copy of its Message Log to 
a secure data storage medium; and 


2.6.3.6 Provide a mechanism for deleting information related to a past election from 
the BCS. 


2.6.3.7 Finalize the Ballot Manifest 
2.6.4 Interfacing with devices 
The BCS software must: 


2.6.4.1 Be capable of interfacing with printer hardware to enable the creation of 
Voting Tickets; 


2.6.4.1.1 If specialized software is used for printing (1.e. API calls within the 
software that goes beyond the use of standard system-level printing 
APIs), then all printer-specific logic must be maintained within a 
Componentized Software Element; 


2.6.4.1.2 Enable configuration of the printer that is used by the BCS software 
in the case that multiple printing devices are being used for the 
election; 


2.6.4.1.3 In the event of a printer device error, or low or insufficient paper, 
provide immediate notification of the condition; 


2.6.4.2 Interface with a COTS barcode reader or other hardware capable of reading 
the Ballot Style code from a Ballot Style Token and the barcode on a Printed 
Vote Record; 


2.6.4.3 Write the EVR Hash to a portable memory device for transferring the data to 
the Voter Check-in Station for transmission by a STAR-Vote™ application 
running on the Voter Check-in Station, where: 


2.6.4.3.1 The application on the Voter Check-in Station transmits the EVR 
Hash to an assigned Receiving Substation, and; 


2.6.4.4 Detect the presence of one or more connected batteries, and provide 
information on the BCS’s power state to the poll worker 
(charging/discharging/connected, % power remaining, etc.). The batteries 
powering the network switches must be connected to a BCS station to be 
monitored, and must be able to be identified and displayed individually. 


2.7 Voting Station Module 


2.7.1 Before the polls open and prior to inclusion in a Polling Location Network, the 
Voting Station Software must: 


2.7.1.1 Accept a complete In Person Election Definition File as produced by the 
Image Creation and Deployment module as part of the System Image 
deployed to the device. This System Image must include all settings that 
must be configured on the device with the exception of the device-specific 
Machine Identifier (MID) and Digital Certificate; 


2.7.1.2 Accept a Digital Certificate specific to this device used to sign all outgoing 
network messages; 


ZA 


2.7.1.4 


Include a unique Machine Identifier (MID). This is a permanent number 
assigned to the machine (or software installation) during its useful life.; 


Establish a Message Log for use throughout the Election. This Message Log 
must: 


2.7.1.4.1 Employ a defined ordering and provide tamper evidence through the 


use of a hash chain; 


2.7.1.4.2 Contain a record of all messages received by the Voting Station via a 


Polling Location Network, and retain all message meta-data; 


2.7.1.4.3 Contain a record of all messages sent by the Voting Station over a 


Polling Location Network, and retain all message meta-data; 


2.7.1.4.4 Contain a record of all device connections/disconnections, or network 


errors; 


2.7.1.4.5 Contain any additional information to enable compiling the Public 
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Audit Log as detailed below; 


Maintain independent public audit hash chains for each Voting Station, in 
each Voting Station. That is, if there are the maximum of 20 Voting Stations 
in a precinct, each machine maintains copies of 20 public audit hash chains — 
one for each Voting Station. 


2.7.2 After a Voting Station is connected to the Polling Location Network, the Voting 
Station software must: 
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Didone 


Begin monitoring for Polling Location Network messages related to the 
election; 


Connect to and accept connections from any device on the network and check 
that it has a valid Digital Certificate issued by the Election Certification 
Authority; 


2.7.2.2.1 If authenticated, note the device role (Voting Station, BCS, Ballot 


Box/Scanner) indicated in the device’s Digital Certificate and only 
treat as valid messages from the device that are appropriate for that 
device role; 


2.7.2.2.2 If not authenticated, refuse to accept messages from the device, and do 


2. 2.3 


2.1.2.4 


not send messages to the device.; 


Send any messages sent over the network to all connected devices except 
where otherwise stated; 


Accept any messages received from an authenticated device; 


2.7.2.4.1 All such messages must be logged in the Message Log; 


2.7.2.4.2 Messages that are received from an authenticated device, but not 
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2.7.2.6 


expected from its device role, it must be ignored once logged and a 
network error reported by a BCS. An example would be receiving a 
“Ballot Submitted” message from a BCS or Ballot Scanner, or a 
“Ballot Cast” message from a Voting Station; 


Every message received must be stored in the Message Log and included in 
the Internal Audit Hash Chain to ensure good ordering and tamper evidence; 


Accept each Ballot Control Station’s Public Key for use in encrypting Page 
Casting Identifiers; 


2.7.2.7 Display in very large text a sequential short identifier that uniquely identifies 
this Voting Station within the precinct as assigned by the BCS. Note that this 
should be distinct from, and not related to, the Machine Identifier. On the 
same screen, in smaller text must be displayed: the assigned Polling Location, 
the assigned Machine Identifier, and whether the voting station is assigned for 
use on Election Day, Early Voting, or both; and 


2.7.2.8 Accept a Launch Code transmitted by one of its BCSs just prior to the 
election’s start. This launch code is included in the Audit Log, and the 
Voting System does not accept an instruction to begin an Election until a 
Launch Code has been received; 


2.7.3 When the Polls Open 


The Voting Station receives notification from a BCS that the election has begun (or 
resumed, if the station is involved in a multi-day election, or the election is 
interrupted), at which time, the Voting Station must: 


2.7.3.1 Provide an appropriate user interface for consuming a Voting Ticket; 


2.7.3.2 Upon entry of a Voting Ticket, encrypt the ticket with the BCS public keys, 
broadcast that a ticket has been consumed along with the encryptions, and 
await confirmation by the BCS that the Voting Ticket is valid; 


2.7.3.2.1 If the Voting Ticket is invalid, provide an appropriate error message, 
and an opportunity to reenter the Voting Ticket. Upon a configurable 
number of consecutive failed entries, notify the BCS of a problem, 
and display an error message indicating that there is a problem and 
that Election Officials have been notified to assist the voter; 


2.7.3.2.2 If the Voting Ticket is valid, the Ballot Style associated with that 
Voting Ticket is provided by the BCS that issued the Voting Ticket 
alongside its confirmation of the Voting Ticket’s validity. The 
system must then: 


2.7.3.2.2.1 Display the Ballot Style provided by the BCS according to 
the Ballot User Interface specifications in this RFP and 
accept the Voter’s selections; 


2.7.3.2.2.2 Generate unique Page Identifiers (PIDs) for each page of the 
Voter’s PVR; 


2.7.3.2.2.2.1 The PIDs are recommended to be Universally Unique 
Identifiers (UUIDs) if deemed feasible; 


2.7.3.2.2.2.2 The PIDs must be created via a cryptographic random number 
generator; 


2.7.3.2.2.3 Calculate an encryption of each PID using the Election 
Public Key, that is referred to as CFP; 


2.7.3.2.2.4 Generate Page Casting Identifiers (PCIDs) for each page of 
the Voter’s PVR; 


2.7.3.2.2.4.1 The PCIDs may be sequential, and are specifically not 
required to be random; 


2.7.3.2.2.4.2 The PCIDs must begin with the Voting Station’s MID 
number; 


2.7.3.2.2.4.3, Each Voting Station must guarantee that every PCID it 
generates during a given election is unique; combined with 


the requirement that the PCID include the Voting Station’s 
MID number, this implicitly requires that each PCID in an 
election be unique; 


2.7.3.2.2.4.4 For Provisional ballots, the final character of the PCID must 
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2.7.3.2.2.6 


ZAR 


2.7.3.2.2.8 


2.7.3.2.2.9 


2.7.3.2.2.10 


be ‘P’; for non-provisional ballots, the final character of the 
PCID must not be ‘P’. The PCID must not directly reflect, 

incorporate, or be dependent upon any other attribute of the 
ballot; 


Calculate an encryption of each PCID using the Election 
Public Key, that is referred to as C¥pcip; 


Calculate an encryption of each PCID using the assigned 
BCS’s Public Key. The combination of these encryptions is 
referred to as Cre; 


Print a human-readable PVR and Voting Receipt according 
to the specifications in this RFP; 


Create an Electronic Vote Record (EVR) from the Voter’s 
selections according to the specifications in this RFP; 


Create a Public Electronic Vote Record (PEVR) based on 
the EVR according to the specifications in this RFP; 


Calculate an audit cryptographic hash for this Voter’s ballot, 
Zi, Of: 


2.7.3.2.2.10.1 The previous ballot’s hash, zi-ı (For the first ballot in the 


election, this is the Audit Hash Chain Seed hashed with the 
Launch Code); 


2.7.3.2.2.10.2 MID, the current time, the Ballot Style, C“pcim, CFecm, C® pn, 
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a hash of the ballot style data used to display this voter’s 
ballot, and the Electronic Vote Record; 


Broadcast and immediately commit to non-volatile memory 
as part of the Voting Station’s Message Log a Ballot 
Submitted message containing MID, the time used in the 
hashes above, the Ballot Style, C“pcim, C¥pcip, C¥ pip, the 
EVR, the PEVR, a hash of the ballot style data used to 
display this voter’s ballot, and the hash zi; 


2.7.3.3 Upon receipt of a Ballot Submitted message from any other Voting Station: 


2.7.3.3.1 Immediately commit the message to non-volatile memory as part of 
the Voting Station’s Audit Logs, and retain the message’s hashes in 
volatile memory for use in validating the next Ballot Submitted 
message from that Voting Station; 


2.7.3.3.2 Store the EVR’s status, keyed to its internal audit cryptographic 


hash; 
2.7.3.3.2.1 


2.1.3:3.2.2 


If the Electronic Vote Record is not provisional, record its 
status as “Submitted;” and 


If the Electronic Vote Record is provisional, record its status 
as “Provisional Pending.” 


2.7.3.4 


Upon receipt of a Ballot Cast or a Ballot Spoiled message from a BCS, the 
status of the associated EVR is updated to “Cast” or “Spoiled” as appropriate 
with an entry added to the Ballot Manifest. 


Additionally, the Voting Station Software must: 


2.7.3.5 


2.7.3.6 


2.7.3.7 


2.7.3.8 


2.7.3.9 


Allow for the connection of a new BCS added to the Polling Location 
Network, accept a new BCS Public Key that is used for encryption of Page 
Identifiers and Page Casting Identifiers; 


Correctly integrate with a Polling Location Network if added to the Network 
mid-election by requesting a copy of one (or more) devices on the network’s 
Message Log(s), and integrating that information into its own Message Log. 
It must be clear in the Message Log that this data was downloaded from 
another device and must include the Machine ID and Digital Certificate of 
that device; 


Provide a mechanism for relaying a complete copy of its Message Log to any 
authenticated device that requests it over the network, with the entire 
Message Log being provided only to the requesting device and a confirmation 
message broadcast to the entire network that the Message Log was 
transmitted and received. This is the only case in which all data that is part of 
a message need not be broadcast to all devices; 


Handle the failure of a BCS when the polls are open; 


2.7.3.8.1 While not connected to a BCS, the Voting Station must continue to 
accept selections from an active voter’s session and allow the voter 
to finish and print the PVR and Voting Receipt. The Voting Station 
must immediately transmit its Ballot Submitted message to the 
network at large and, once a BCS is connected, transmit it 
exclusively to the BCS; 


2.7.3.8.2. While disconnected from a BCS and not enabled for voting, the 
screen used for accepting Voting Tickets must be replaced by a 
message screen indicating that the machine is not currently usable; 


2.7.3.8.3 The disconnection event must be noted in the Voting Station’s 
Message Log; 


Handle a temporary disconnection from the BCS or the Polling Location 
Network; 


2.7.3.9.1 The Voting Station must have the capacity to reconnect to the 
network and any connected BCS without human interaction or 
guidance; 


2.7.3.9.2 While disconnected, the Voting Station must continue to accept 
selections from an active Voter’s session, and allow the voter to 
finish and print the PVR and Voting Receipt. Once a connection to 
a BCS is reestablished, the Voting Station must immediately 
transmit its Ballot Submitted message to the network at large if the 
network is available, and, once a BCS is connected, transmit it 
exclusively to the BCS; 


2.7.3.9.3 While disconnected, the screen used for accepting Voting Tickets 
must be replaced by a message screen indicating that the machine is 
not currently usable; 


2.7.3.9.4 Any such event must be noted in the Voting Station’s Message Log; 


2.7.3.10 Provide updated information via network broadcasts a configurable number 
of seconds, with the default 60 seconds, regarding system status, including: 


2.7.3.10.1 Power state (running on external AC power, running on battery 
power, battery charge status, etc.); 


2.7.3.10.2 Other system status that the vendor deems relevant to monitoring 
and maintaining the health and functioning of the Voting Station, 
but does not provide any information about the status of a voter 
making use of the Voting Station, where the minimum requirement 
is for a ‘heartbeat’ message; 


2.7.3.10.3 Ifa Voting Station switches from Mains Power to battery power, a 
status message is sent immediately. 


2.7.3.11 Detect any error event or state that could adversely affect the ability of the 
Voting Station to function properly and: 


2.7.3.11.1 Immediately broadcast the problem and relevant supporting 
information to the network, provided that information is in no way 
related to the state of the voter’s selections; 


2.7.3.11.2 If the Voting Station is currently in use by a Voter and the state 
affects the ability of the Voting Station to complete the voting 
session, immediately display an error message indicating that an 
error has occurred and election officials have been notified to assist; 


2.7.3.12 Support use for curbside voting. Upon entry of a Voting Ticket designated as 
curbside voting, the Voting Station sends a message to the BCS indicating 
that it is to be used for curbside voting: 


2.7.3.12.1 Accept a Voting Ticket and display the ballot style that includes a 
message on the screen that the unit is for curbside use only; 


2.7.3.12.2 Allow the Voting Station to be disconnected from the polling 
location network without sounding any alarms or displaying or 
attempting to broadcast an error state; 


2.7.3.12.3 While disconnected: 


2.7.3.12.3.1 Allow the voter to vote as though he or she is at a Voting 
Station in the polling location attached to the polling 
location network; 


2.7.3.12.3.2 Any error information that would typically be provided to 
the poll workers at the BCS must be available through the 
Voting Station without reconnecting to the BCS; 


2.7.3.12.3.3 Store each message that would typically be transmitted 
during or after the voting process until reconnected to the 
polling location network; 


2.7.3.12.4 Once reconnected to the polling location network: 
2.7.3.12.4.1 Broadcast all stored pending messages; 


2.7.3.12.4.2 Collaborate with one or more other devices on the network 
to reconstruct the parts of the message log that the device 
has missed by being disconnected; 


2.7.3.13 If the network cable is disconnected during an election and the Voting Station 
is not currently set to be used for curbside voting, detect this change and 
provide a quietly audible alarm and a visual message identifying the Voting 
Station at the BCS . This alarm must: 


2.7.3.13.1 Automatically raise the system volume to a volume determined 
during configuration to ensure the alarm is not “muted” at the 
system level; and 


2.7.3.13.2 Be able to be disabled during device configuration. 


2.7.3.13.3 A noticeable visual indication must be provided on the BCS display 
2.7.4 After the Polls Close 


Once an election has been completed, the Voting Station must: 


2.7.4.1 Continue to support network connections and log and fulfill requests over the 
network for a full copy of its Message Log; 


2.7.4.2 Provide a means for generating and displaying the Data Integrity Audit Hash, 
which is a cryptographic hash of the complete election data collected from 
that day. Allow the Audit Hash to be printed out using the same printer as is 
used to generate Voting Tickets with both a human-readable version and a 1- 
D barcode version; and 


2.7.4.3 Provide a mechanism for transferring a complete copy of its Message Log to 
a secure data storage medium. 


2.7.5 Interfacing with devices 
The Voting Station must: 


2.7.5.1 Be capable of interfacing with and making use of any printer device that can 
be successfully attached to, and configured for use on, the Voting Station 
hardware, and that meets the specifications for the Ballot and Receipt Printer, 
as specified in this RFP. If specialized software is used for printing (i.e. API 
calls within the software that go beyond the use of standard system-level 
printing APIs), then this requirement may be met by containing all printer- 
specific logic within a Componentized Software Element; 


2.7.5.2 Prior to the election, enable configuration of the printer to be used by the 
Voting Station in the case that multiple printing devices are being used for the 
election. ; 


2.7.5.3 In the event of printer device error or insufficient paper, immediately notify: 
2.7.5.3.1 The network of the error or issue; 


2.7.5.3.2 The current voter that an error or issue has occurred and stating that 
election officials have been notified; 


2.7.5.4 Detect the presence of one or more connected batteries, and provide 
information on the Voting Station’s power state to the network (at a 
minimum: charging/discharging/connected, % power remaining); and 


2.7.5.5 Detect and disallow printing to non-physical print devices (such as PDF 
printers or other virtual printers). 


2.7.6 Support for Accessibility Hardware 


As stated in the VVSG specifications for Accessible Voting Stations (Acc-VS), the 
system must: 


2.7.6.1 Support voters requiring accessibility considerations; and 


2.7.6.2 Make use of COTS accessibility hardware, whenever possible, as a First-class 


2.7.1 


Input Mechanism. 
Demonstration Mode 


The system must provide: 


2.7.7.1 That Voting Stations be able to be designated as demonstration units during 


initialization; 


2.7.1.2 Demonstration units that can be pre-loaded with one or more ballot styles, 


separate from the actual election’s ballot styles (these would typically be 
reduced-size versions of actual ballot styles with substitutions of fictional 
names and/or races); 


2.7.7.3 Demo units with the means to be locked down in demonstration mode, such 


that it can only be changed by the Administrator, and: 


2.7.7.3.1 Must give the voter the same experience as the complete Ballot 
User Interface with a full-fidelity voting station, with the exception 
that the Voting Ticket screen is given a fixed ticket code; 


2.7.7.3.2 Must not provide the ability to print a ballot, but provide 
instructions on the steps that would follow in the actual voting 
situation; and 


2.7.7.3.3 Must not allow the voter or anyone but the Administrator to access 
any other software or disable demonstration mode. 


2.8 Data Integration/Validation Module 


The system must: 


2.8.1 
2.8.2 


2.8.3 


2.8.4 


Accept an In Person Election Definition File; 


Accept, either via a local Ethernet network, or via COTS removable storage, the 
election data stored on, or written by, a BCS or Voting Station; 


For each polling location from which data is accepted, present a hash of the data for 
comparison to the hash generated at the polling location (to verify that the data was 
not altered in transit); 


Once data is accepted from a polling location, validate: 


2.8.4.1 That digital signatures on elements within the data are valid and correspond 


to digital certificates issued or signed by this election’s Election Certification 
Authority; 


2.8.4.2 That hash chains are valid and intact; 
2.8.4.3 That NIZK proofs embedded in the EVRs are valid and that EVRs are well- 


2.8.5 


formed; 


On demand, generate a report stating every polling location for which data is 
received, and for each polling location, the date and time at which data is received, 
the MID of the device from which the data is received, the means by which the data 
is received (network or removable media), the hash of the data, and whether the 
data passes all validation checks; 


If any validation checks fail for a polling location’s data, provide a report 
specifying the type of error and details of where the error is detected in the data (for 


2.9 


example, the specific EVR at which a hash chain is broken, or for which NIZK 
proofs are invalid); 


2.8.7 Via the connected Ethernet network, provide all relevant validated data to the 
Tabulator Module; and 

2.8.8 Provide a means for an administrator to specify that a specific polling location’s 
data that failed validation be sent to the tabulator regardless. 

Trustee System Module 

2.9.1 This system must include a stripped down operating system distribution (such as a 
minimal Linux distribution or alternatives that achieve the same purpose) with a 
single piece of user-accessible software called the Trustee Software; 

2.9.2 The operating system distribution should include only the elements necessary to run 


that software, and should boot directly in to it. 


The Trustee Software must: 


2.9.3 


2.9.4 


2.9.5 


2.9.6 


2.9.7 


2.9.8 


2.9.9 


Allow for Trustee computers to independently generate and store public/private key 
pairs for the encryption algorithm chosen in compliance with this section and 
compatible with the homomorphic encryption algorithm used in EVRs; 


Enable several Trustee computers, networked using the Network and Logging 
Layer as described in this RFP, to cooperate to create a threshold public key (with a 
configurable threshold) overseen by a networked Tabulator; 


Not, in any circumstance, divulge even to the software’s user a created private key, 
each of which must be stored in the computer’s Trusted Platform Module (TPM) for 
further security; 


Support the use of Hardware Security Modules (HSMs) for storing high-value keys 
and performing essential cryptographic operations; 


Support the verifiable mix (via a cryptographic mixnet) and decryption of any data 
encrypted with that threshold key, when threshold number of Trustee computers are 
present, supervised by a networked Tabulator. Optionally, the cryptographic mixnet 
may be split out into an additional independent component to further 
compartmentalize the code; 


Not have any domain-specific knowledge — rather, it must only expose general 
functions for performing cryptographic operations on arbitrary data, and for 
appropriate key generation; 


Enable communication over a connected Ethernet network via the shared Network 
and Logging Layer, provided that: 


2.9.9.1 Any action requested by other devices on the network be approved by the 


user before being executed; 


2.9.9.2 All network communication is logged; 


2.9.10 While communicating over a connected Ethernet network, provide the following 


services to connected devices: 


2.9.10.1 The public key when requested; 


2.9.10.2 Participation in the creation of a threshold, commitment consistent public 


key; 


2.9.10.3 Participation in the decryption of Encrypted Vote Tallies; 


2.9.10.4 


2.9.10.5 


2.9.10.6 


2.9.10.7 
2.9.10.8 


2.9.10.9 


Participation in the mixing and decryption of Single Race Selection Vectors 
(In this instance, ‘mixing’ refers to the application of a verifiable 
cryptographic mixnet. The goal of this action is to obscure the 
correspondence between decryptions of Single Race Selection Vectors and 
their encryptions.); 


During all activities, provide reasonable status information to the user 
including an estimate of the time remaining to complete the operation during 
any operation that would normally take more than a few seconds; 


While participating in the decryption of the Encrypted Vote Tallies when the 
tally has been completely decrypted by the networked Trustee Computers, 
automatically display the top-level results of the tally as soon as they are 
available, and without prompting by the user; 


Participation in the decryption of the RLA Ballot Manifest. 


Make available a user-accessible facility for exporting tallies (including all 
breakdowns of tallies required elsewhere by this document or by applicable 
law), audit logs, and proofs of all exported tallies; 


Use key lengths and hash sizes that meet or exceed the minimum bit length 
recommended for Level 7 security as described in section 7.2 of the 
ECRYPT II Recommendations, ICT-2007-216676 (2011); 


2.9.10.10This implies at minimum: 128-bit symmetric keys, 3248-bit asymmetric keys 


and logarithm group keys, 256-bit Elliptic Curve group keys, and 256-bit 
hashes; 


2.9.10.11This may be reduced to Level 6 security provided that the homomorphic 


encryption Algorithm Selected does not require the release of full cyphertexts 
of encrypted ballots to enable independent homomorphic calculation of a 
commitment-consistent encrypted vote tally by members of the public; and 


2.9.10.12Generate all encryption keys independently — i.e. individual trustee keys may 


not be jointly derived from a single master key or key pair. 


2.10 Tabulator Module 


To facilitate vote tallying and auditing, and using the shared Cryptographic System, in the 
post-Election period the Tabulator Module must: 


2.10.1 Accept a complete audit log from each polling location, the Provisional Integration 
and Acceptance Software, and support extracting from them a complete set of 
EVRs for the election; 


2.10.2 Verify that hash chains in the supplied Election Vote Records are valid; 


2.10.3 Calculate aggregations of all EVRs that are marked as “cast” or “provisional 
accepted” by precinct, by the ballot box in which its resulting PVR is placed, and by 
election using the homomorphic property of the vote count’s encryption, to create 
Encrypted Vote Tallies; 


2.10.4 Provide a mechanism for incorporating adjustments into the calculation of tallies (in 
the case of incorporating other jurisdictions’ results, or to correct for unusual 
events, for example). To facilitate this: 


2.10.4.1 Enable adjustments to be entered for each relevant candidate by precinct, 


generating a new EVR for each precinct containing the adjustments for that 
precinct. These EVRs do not need to include NIZK proofs of correctness; 


2.10.4.2 Include the adjustment EVRs, which may include multiple votes cast for 
individual candidates or contests, in any relevant tallies decrypted and 
verified by the Trustees; 


2.10.4.3 Include these adjustment EVRs in the final set of public EVRs released, but 
include the randomness used to encrypt the adjustment EVRs so that they 
may be readily decrypted and verified by members of the public; 


2.10.4.4 Provide a clear way of recognizing, from the data in the EVR, that it is an 
adjustment, not a valid cast ballot; 


2.10.5 Pre-process the EVRs into Single Race Selection Vectors to prepare for the 
generation and decryption of the Audit Plain Text Commitment files. The final 
Audit Plain Text Commitment files shall include, at a minimum, the following data 
elements for each Race in the election: 


2.10.5.1 Hash of the PID and Race name/ID; H (PID n || Race m) 
2.10.5.2 Each candidate for the Race with encrypted vote selection: ENC(0/1) 
2.10.6 Manage the distributed activities of the networked Trustee Computers: 


2.10.6.1 Verifiably mix and decrypt the set of accepted Provisional PIDs, and use this 
to assign each “Provisional Pending” ballot a status of either “Provisional 
Accepted” or “Provisional Rejected;” 


2.10.6.2 Integrate “Provisional Accepted” EVRs into the Encrypted Vote Tallies 
calculated above; 


2.10.6.3 Decrypt the Encrypted Vote Tallies, giving a complete tally of all votes cast 
for each; 


2.10.6.4 Decrypt all Single Race Support Vectors corresponding to PVR pages that 
have been spoiled. Portions of Electronic Vote Records that are not “cast” or 
“spoiled”, and that are not provisional, are assumed spoiled and decrypted; 


2.10.6.5 Mix and decrypt all write-in slots; 


2.10.6.6 Verifiably mix and decrypt all of the encrypted values in each Single Race 
Selection Vector from each EVR; 


2.10.6.7 Decrypt the RLA Ballot Manifest 


2.10.6.8 As required to verify claims of election problems, the election management 
software must have a means to accept a PEVR Hash (as found on a voter’s 
Receipt) by scanning the barcode on that Receipt, or by typing in the code. 
The system must then have the Trustee Computers decrypt the PID and PCID 
for each page of that record’s associated PVR, and provide them to Election 
Officials, along with the ballot box in which that PVR’s pages must be 
found; 


2.10.7 Provide vote tallies based on the information decrypted above for each aggregation 
of EVRs for publishing; 
2.10.7.1 Tallies must be exportable in multiple formats. At a minimum: 
2.10.7.1.1 A defined standard for eXtensible Markup Language (XML) or 


JavaScript Object Notation (JSON) or other suitable Human 
Readable format; 


2.10.7.1.2 As a hard-coded PDF report; 


2.10.7.1.3 In such a format as to be successfully consumed by the County’s 
existing election night reporting system without alteration; 


2.10.7.1.4 Tab or comma delimited text file; 


2.10.7.1.5 The file format agreed to between successful proposers of Elements 
A and B during contract negotiations. 


2.10.7.2 Provide a mechanism for creating and publishing sufficient data such that 
independent observers can verify that the encrypted published vote totals 
correspond precisely to the aggregation of the published, encrypted, cast 
ballots. This includes: 


2.10.7.2.1 The Encrypted Vote Tallies; 


2.10.7.2.2 PEVRs derived from each Electronic Vote Record, and the Audit 
Hash associated with each PEVR; 


2.10.7.2.3 All information necessary to validate the public hash chains in the 
encrypted ballot information above; 


2.10.7.2.4 The information that is needed to prove that the tallies are consistent 
with the information stored in the released PEVRs; 


2.10.7.2.5 The Audit Plaintext Commitment File; and 


2.10.7.2.6 The plaintext decryptions of each spoiled EVR, including the 
decryption of the randomness from each SRSV so that the 
decryption can be verified. The option must exist for inclusion of 
the decrypted EVRs and associated randomness to be disabled by 
election administrators. 


2.11 Provisional Ballot Resolution and Acceptance 


The provisional Integration and Acceptance Software enables resolution of provisional 
ballots and acceptance of provisional ballots separate from a polling location. 


This software must: 
2.11.1 Enable the acceptance of Provisional ballots at any time up until final canvass; 
2.11.2 When a provisional ballot is to be accepted: 


2.11.2.1 Allow for the PID on each PVR page to be scanned via its barcode. This 
can optionally be accomplished by requiring that it be fed into a Ballot 
Box/Scanner; 


2.11.2.2 Encrypt each PID with the Election Public Key for ultimate decryption 
by the Trustees; 


2.12 In-Person Voting/Tabulation Reports 


The following is a list of reports that are used regularly and that the In-Person 
Voting/Tabulation module and the Support Modules must be able to produce: 


2.12.1 Device Preparation Reports 


The following includes, but is not limited to a list of Administrative reports for a 
specified election: 


2.12.1.1 Device ID report listing each BCS and Voting Station and the ID 
associated with each device; 


2.12.2 


2.12.1.2 


2:12:13 


2.12.1.4 


2121.3 


2.12.1.6 


2.12.1.7 


2.12.1.8 


2.12.1.9 


Device and ballot style report listing each BCS with the device ID and 
the precinct/ballot styles assigned to each device; 


Device and polling location assignment report listing each BCS with the 
device ID and Voting Station and the polling location assigned to each 
device; 


Back up (emergency) device report listing all BCSs with device IDs 
assigned as back up (emergency) devices, the status of each device 
throughout the election (deployed or not deployed), and the polling 
location, if deployed; 


Pre-election functional testing report documenting each stage of 
functional testing of all equipment used to vote, print, count, and 
tabulate ballots with their device IDs; 


Zero report documenting that a Voting Station is deployed with no votes 
recorded. 


Zero reports must support efficient Election Day voting sites, in both 
electronic and paper formats. 


Zero reports must support efficient Early Day voting sites, in both 
electronic and paper formats. 


Zero reports must support efficient Vote Center Day voting sites, in both 
electronic and paper formats. 


Polling Location Reports for Every Day of Early Voting and Election Day 


The following includes, but is not limited to a list Administrative and polling 
location reports for a specified election: 


2.12.2.1 


2.12.22 


22.5 


Zero reports used on the first day of Early Voting and at the opening of 
Election Day. A zero report documents that no votes are on the device at 
the time it begins service for an election. 


Daily reports created at the start of each day of Early Voting that 
document the cumulative number of votes cast at that location by that 
date for that election; 


Daily closeout reports at an Early Voting polling locations that include: 


2.12.2.3.1 The total number of Voting Tickets issued at each BCS. There 


must also be a breakout showing the status subtotals for this 
number including the number of tickets voted, expired, 
canceled, spoiled/challenged, voted provisional, or left behind 
without explanation by a voter; 


2.12.2.3.2 Votes cast report documenting the number of votes cast on the 


BCS (including a provision to include the number of 
emergency ballots issued and cast); 


2.12.2.3.3 Total votes cast report documenting the total number of votes 


cast at that location for the entire election; 


2.12.2.3.4 Polls closed reports that contain audit information and the 


Election Data Integrity Hash. 


2.12.3 Daily Detail Summary Reports for Early Voting 


2.12.4 


2.12.5 


2.12.3.1 Ballot allocation report listing the number of Voting Tickets used for the 
day broken down by status (voted, expired, canceled, 
spoiled/challenged, voted provisional, or left behind without explanation 
by a voter), precincts voted and number of Voting Tickets by precinct 
for all ballots issued in the polling place. Election title, date and time 
are used to identify the Daily Detail Summary, and; 


2.12.3.2 Polling location device activity report listing machine IDs in operation 
and the breakdown of activity of each machine for the categories listed 
above for any given day or the entire voting period as well as summary 
numbers for a location on any given day or for the entire voting period. 


Close of Polls on Election Day 


2.12.4.1 Summary of the total number of Voting Tickets issued and a breakdown 
of the status of each. 


2.12.4.2 Detailed results by precinct report for Election Day voting sites. 
2.12.4.3 Detailed results by precinct reports for Vote Center voting. 


2.12.4.4 Close of Polls reports are required to be produced in 15 minutes or less 
for both Electronic and paper formats. 


Central Counting Station (CCS) Reports 


All CCS reports must be relayed in real time throughout election night. These 
reports are not one-time, end-of-night reports. Some reports may continue to be 
used through to the final canvass. The list of these reports includes: 


2.12.5.1 Device integrity report validating that the BCSs or Voting Stations 
delivered tothe CCS have not been altered or tampered with; 


2.12.5.2 Receiving Substation (RSS) physical security assignments report for 
seals-or other forms of physical security assigned at the RSS for 
transport to CCS; 


2.12.5.3 Polling locations/RSS assignments report listing which locations go to 
which RSS; 


2.12.5.4 Closed poll audit report that displays, compares, and analyzes close out 
information from the polling locations, RSS, and Central Counting 
Station, and tabulation reports from the Reporting Module. 


2.12.5.5 Hash code compilation report documenting the hash code compilation of 
all results by location from the tabulation software; 


2.12.5.6 Early Voting (EV) in-person tabulation reports documenting the number 
of ballot-by-mail and EV in-person votes cast with and without 
provisionals; 


2.12.5.7 Raw cumulative report representing a basic raw report from the 
tabulation software of all cumulative and precinct contest results with 
and without over votes and under votes; 


2.12.5.8 Locations reported/not reported report from the tabulation software 
listing all locations reported and not reported on election night; 


2.12.5.9 Total number of votes cast report from the tabulation software 
documenting the total number of votes cast (including and not including 


provisional votes and spoiled ballots) in each location to compare 
against the reports received from the polling locations; 


2.12.5.10Provisional compilation report from the tabulation software of all 
provisional ballots cast by location and precinct/ballot style; and 


2.12.5.11Spoiled/challenged ballot compilation report from the tabulation 
software of all spoiled ballots by location and precinct. 


2.12.6 Post-election-night Reports Not Addressed in CCS Reports Section 
These reports include: 


2.12.6.1 Number of Provisionals accepted and rejected report from tabulation 
software documenting the total number of provisional ballots accepted 
and rejected by polling location; 


2.12.6.2 Device and polling location assignment report listing each BCS and 
Voting Station, the polling location assigned to each device, and the 
number of votes assigned, cast, cancelled, spoiled, and expired on each 
device; 


2.12.6.3 Device integrity report validating that the BCSs or Voting Stations 
delivered to the RSS from the polling locations have not been altered or 
tampered with; and 


2.12.6.4 Device association report listing the ID numbers of each BCS and the ID 
numbers of the Voting Stations initially assigned to each BCS, and in 
comparison, the ID numbers of the Voting Stations that were actually 
connected to each BCS at any time during the voting period. 


2.12.7 Election Backup and Archiving 


The following includes, but is not limited to a list of reports necessary for backup 
and archiving: 


2.12.7.1 Device ID report listing each BCS and Voting Station, the ID associated 
each device, and the vote totals cast on each device; 


2.12.7.2 Device and ballot style report listing each BCS with the device ID and 
the precinct/ballot styles assigned to each device and the number of 
votes cast on each ballot style; 


2.12.7.3 Device and polling location assignment report listing each BCS with the 
device IDs and Voting Station IDs and the polling location assigned to 
each device; and 


2.12.7.4 Back up (emergency) device report listing all emergency BCSs and their 
associated IDs showing a final status of not deployed along with a zero 
report for confirmation. 


2.13 Risk Limiting Audit Support Module 


The STAR-Vote™ system must support risk-limiting audits by generating random samples, 
reconstructing electronic records for comparison, and managing statistics. This risk-limiting 
audit support software must integrate the data produced by the Election Trustees and simplify the 
process of running the audit as much as possible. In particular, the software must: 


2.13.1 Accept a random seed from which all successive random selections are derived 
using a publicly available cryptographic random number generation system that is 
disclosed; 


2.13.2 Accept a confidence level to be required from the Risk Limiting Audit; 


2.13.3 Generate, using the contest margin of victory in each race, and the known races 


2.13.4 


2.13.5 


2.13.6 


2.13.7 


2.13.8 


on each ballot style page, the number of each ballot style pages that must be 
randomly verified to achieve the accepted confidence level. These calculations 
must be in accordance with Dr. Philip Stark’s work available at this website: 


http://stat-www.berkeley.edu/~stark/Java/Html/auditTools.htm 


Accept electronic Ballot Manifest created by the BCS/Voting Station/Ballot Box 
Scanner that is a list of the PCIDs of each PVR page expected to be found in 
each Ballot Box, including for each the Ballot Box in which each is expected to 
be found The RLA Ballot Manifest shall include, at a minimum, the following 
data elements: 


2.13.4.1 PCID of the ballot 

2.13.4.2 Precinct name or number 

2.13.4.3 Ballot Box ID where the ballot is located, and; 
2.13.4.4 Hash of the PID and Races; H (PID i || Race j) 


Enable election officials to provide an estimated page count in each ballot box 


based on the use of a counting scale and provide a report of the deviation of each 
ballot box from the expected count; 


2.13.5.1 If any ballot box has a statistically significantly different estimate for the 


number of pages than is expected, flag it to possibly be manually 
checked; 


Using known information about the number of each ballot style page that is 
expected to be in each ballot box and their associated PCIDs, produce a list of 
randomly selected paper ballot pages consistent with the numbers calculated using 
the Stark calculations (described above): 


2.13.6.1 These should be of the form: “The PVR Page with PCID xxxxxxxx in 
ballot box yy,” grouped by ballot box. Alternative formats are 
acceptable so long as the same information is provided. 


2.13.6.2 The formula used in producing this list is ultimately disclosed so that 
independent third parties can precisely reproduce, from the random seed 


and publicly released election data, the exact same list of randomly 
selected ballots; 


Provide the means for a user to load the list of randomly selected paper ballot 
pages produced in 2.12.4 segregated by ballot box, onto a computer connected to 
a high-speed scanner, feed the entire content of the ballot box ballots into the 
scanner and out sort the randomly selected ballots. Out-sorting can be performed 
mechanically by the scanner or the scanner can be caused to stop when a selected 
ballot is identified and the ballot manually retrieved from the scanner. If using 
the latter method, the scanner should be able to resume scanning until all selected 
ballots are retrieved from the ballot box. A hand barcode scanner should also be 
provided to scan individual PCIDs 


Provide a means for the user to enter the PID from the ballot page, both by hand 
or using a barcode scanner, and immediately: 


2.13.8.1 Using the PID, page number, and ballot style of the PVR page, 
determine the votes from the Audit Plaintext Commitment File that are 
expected to be found on that ballot page; 


2.13.8.2 Display the PID, ballot style, ballot style page, and reconstructed 
electronic ballot for viewing by the public observers and audit 
personnel; 


2.13.9 For each ballot checked, provide a means to indicate any electronic votes that do 
not match the paper votes. Additionally, provide a means to indicate that the 
ballot was not found; 


2.13.10After all ballots have been checked, if any errors are encountered, generate the 
number of new samples needed, and continue as above until either: 


2.13.10.1A complete list is finished with no errors, or 
2.13.10.2The confidence in the manual count increases to 100%; 


2.13.11 The RLA support utility must include provisions for the users to calculate 
relevant statistics based on the margin, results, error bounds, number, size of the 
audit units for one or more stages of audits as outlined by the Stark audit tools 
and/or the Open Source RLA module developed by Neal McBurnett as 
published at: 


https://launchpad.net/electionaudits 


2.13.12 Audit Termination: the audit can be terminated when one of the follow 
conditions are met: 


2.13.12.1 The Risk Limit is achieved from the stage 1 audit that confirms the 
committed contest winner based on the outcome reported by the 
Tabulation module, where the audit size is determined by the RLA 
support utility; or 

2.13.12.2 The Risk Limit is achieved after stage N, where additional audit unit 
sizes are determined by the RLA support utility and confirms the 
contest winner reported by the Tabulation module; or 


2.13.12.3 A full hand count of all ballot determines the contest winner 


APPENDIX C 
SUPPORT MODULES 


3.0 REQUIREMENTS FOR SUPPORT MODULES 
Sample Ballot and Public Web View Module 


3.1 


3.1.1 


3:1:2 


Sample Ballots in Voting Station Format 
The system must: 
3.1.1.1 Allow the printing of each ballot style for use as a sample ballot. 


3.1.1.2 Provide a means for placing a watermark across a sample ballot that says, 
“Sample Ballot.” This watermark must be easily picked up by a 
photocopier, but should not obscure any language on the ballot. 


Comprehensive Sample Ballot 


In addition to sample ballots by ballot style, the system must be able to generate a 
Comprehensive Sample Ballot (sometimes called a “bedsheet ballot”) that 
includes all elections and all races to be conducted within the County on a 
particular election date. An example of this type of sample ballot is provided in 
Attachment 7. The system must: 


3.1.2.1 Provide a customizable template for creating a comprehensive sample 
ballot. Below each race, the administrator must be able to select or 
unselect whether or not the list of applicable precincts is included; and 


3.1.2.2 Provide the ability to export the information to an MS Word document 
where it can be formatted for final use. 


3.1.2.2.1 The export must use the Microsoft Office Open XML document 
format for Word (*.docx file); and 


3.1.2.2.2 The software for exporting to this format must not rely on an 
installation of Microsoft Office being available on the computer, or 
on any library that is not deployed with the software itself (aside 
from standard operating system files). 


3.2 Web Voter Ballot Style Lookup and Viewer System 


3.3 


The County Clerk’s website allows voters to look up their voter information and view 
sample ballots that pertain to their location within the County. The system must take the 
data output, as well as exported data from the voter registration system, and enable a 
voter, through a web interface, to look up his or her ballot for an upcoming election and 
see precisely what will be seen/heard on Election Day. 


The system must have an interface with the website that allows the voter to: 


3.2.1 


3:2:2 


View and print a PDF copy of the sample ballot associated with his or her ballot 
style; and 


Download the election’s sample ballot in any applicable language and include all 
elections, races, candidates, and proposition language. Each race must list all 
precincts eligible to vote in those races. 


In-Person Device Initialization and System Load Module 


This should be a recommended commercially-available system for deploying System 
Images, with a STAR-Vote™ specific piece of software that handles providing data for a 


specific election to those machines, along with any information relevant to that specific 
Voting Station or Ballot Control Station. This piece of software must be able to be run on 
multiple computers simultaneously so that voting stations can be initialized in parallel. 
This set of software must: 


3.3.1 Accept a “clean” System Image that can be deployed to all of the voting stations 
before each election; 


3.3.2 Provide a means of initializing each voting station and each BCS that receives the 
System Image with the election-specific data necessary to function as part of its 
assigned polling location. This includes, at a minimum: 


3.3.2.1 A digital certificate specific to that device; 
3.3.2.2 The Election Definition data; 


3.3.2.3 Any additional supporting information required for the device to function in 
its specified role at its specified location; and 


3.3.3 Provide an efficient mechanism for parallel initialization, deployment of System 
Images, backing up, archiving, and removal of past election data. 


4.0 REQUIREMENTS FOR DATA COLLECTION, AUDITING, AND TESTING MODULES 


4.1 


In-Person Voting Test Data Generator 


Extensive testing must be performed to confirm that every aspect of the voting system is 
accurate before it is deployed in the field. Numerous logic and accuracy tests are 
performed to make certain the system is correctly recording and tabulating the results for 
every candidate and option in every ballot style. This module is not networked to the EAC 
Certified Module. It efficiently generates data to test functions such as: the accuracy of 
ballot content and styles; electronic ballot generation and tabulation; the processing of 
challenged/spoiled, provisional, and limited ballots; encryption processes and tabulation, 
the Trustee system, the Bulletin Board; reporting; and risk-limiting audits. Testing routines 
must meet or exceed all laws and Texas Secretary of State guidelines. 


The system must: 


4.1.1 Accept an Election Definition File and perform a comprehensive test of all the 
functions of the voting system, from ballot content to risk-limiting audits; 


4.1.2 Create test data for all or part of the system, and if necessary, multiple versions of 
that test data; 


4.1.3 Allow test data to be created for isolated portions of the ballot; 
4.1.4 Generate test files in a logical sequence and/or allow that data to be randomized; 


4.1.5 Generate Logic and Accuracy test materials and strategies for any given election by 
producing test data that includes, but is not limited to data for: 


4.1.5.1 Ballot Control Station(s) and Voting Stations by generating spreadsheets or 
test ballots (including Challenge ballots) for which the results are already 
known and can be voted through the BCS and the Voting Stations; 


4.1.5.2 The test data must account for and include materials to test special election 
scenarios, such as: 


4.1.5.2.1 Primary and General elections with Federal only ballot styles; and 


4.1.5.2.2 Straight party races, write-in races, multiple candidate races (vote 
for one, two, three, or more). 


4.2 Data Collection, Auditing, and Testing Module for In-Person Voting Module 


This module resides on the laptops used at the polling locations for Voter Check-In, on a 
computer used to track the receipt of daily Early Voting BCSs, at the office of the 
Administrator, at each Receiving Substation, and the Central Counting Station. The 
purpose of this module is to create a chain of custody, confirm data and equipment is not 
tampered with during transport or storage, and transmit election results. 


4.2.1 For purposes of this module, “audit data” from a polling location, during each day 
of Early Voting and on Election Day, is defined as consisting of (at a minimum): 


4.2.1.1 Time polls opened and closed, 


4.2.1.2 Time at which each BCS, Voting Station, and Ballot Box/Scanner were 
connected to the network and, for any of these devices later disconnected 
from the network prior to the close of the polls, the time the device was 
disconnected; 


4.2.1.3 Number of Voting Tickets issued by the BCS; 
4.2.1.4 Number of votes cast; 

4.2.1.5 Number of emergency ballots cast; 

4.2.1.6 Number of provisional ballots cast; 

4.2.1.7 Number of spoiled/challenged ballots that occurred; 
4.2.1.8 Election Data Integrity Hash 


At the Polling Location: At the close of the polls (or if a BCS is being removed from a location), 
the poll worker prints out a receipt with a barcode from the BCS with audit data, the date and time 
the receipt was run, the device ID of the BCS, the polling location, and a hash code of the 
encrypted electronic vote records (EVR Hash). Using the Voter Check-In Station, this data is 
transmitted. If it is during Early Voting, the information is transmitted to the Administrator. If it 
is an Election Day, it is sent to the Administrator, each Receiving Substation, and the Central 
Counting Station. 


At the Receiving Substation: As poll workers arrive, RSS workers download the election data 
from the BCS, and from this, print the audit data, the date and time the receipt was run, and the 
EVR Hash from each BCS. The RSS workers also review and add data such as the number of 
signatures they count on the poll lists. If inconsistencies are found, the system allows the RSS 
worker to enter in explanatory data or to attach a scanned copy of an affidavit. The collected data 
is sent out to the Administrator, the other RSS stations, and the Central Counting Station. 


At the Counting Station: When the BCS arrives at the Counting Station, the RSS receiving 
process is repeated now indicating that the Central Counting Station Judge has received the 
information. The receipt showing the date and time of the printing, audit data, and the EVR Hash 
is printed from the data downloaded from the BCS or Voting Station and scanned into the CCS 
copy of the module. The system allows the Central Counting Judge or Administrator to scan and 
attach any relevant affidavits. 


This module continuously collects and compares information and highlights any inconsistencies. 
For each inconsistency, there is a place to document results of any reviews conducted. There is a 
way for a sign off to be notated to indicate that all the data for that polling location has been 
reviewed. 


The system must: 


422 


4.2.3 


Provide a means for Receiving Substations and the Central Counting Station to 
collect, easily view all location information, monitor, archive, and prepare reports 
using the data collected from all locations. 


Perform validity checks on any election data received including (but not limited 
to): 


4.2.3.1 Validation of hash chain integrity; 
4.2.3.2 Verification of NIZK proofs; If complete NIZK validation is deemed too 


computationally expensive once a practical system is available to evaluate, a 
small random sample of the NIZKs may be validated by this module instead; 


At the polling location, the system must: 


4.2.4 


4.2.5 


4.2.6 


Provide a means for Receiving Substations and the Central Counting Station to 
collect, easily view all location information, monitor, archive, and prepare reports 
using the data collected from all locations. 


Make use of an attached 2-D barcode scanner to read the barcode containing the 
Election Data Integrity Hash from BCS printouts; and 


Provide a means of transmitting over the internet the polling location and Election 
Data Integrity Hash (as scanned from a BCS printed barcode) to the 
Administrator, RSS, and CSS (as needed). These data must be transmitted 
securely, using industry standard technologies for transmitting secure data across 
public networks; 


4.2.6.1 This module include a software communication application for transmitting 


the above information in a secure manner. The software communication 
application is installed on the Voter Check-in station computer as part of the 
election set up process.; 


At the RSS, the system must: 


4.2.7 


4.2.8 


4.2.9 


4.2.10 


4.2.11 


4.2.12 
4.2.13 


4.2.14 


Provide a means of securely receiving (over the internet) the Election Data 
Integrity Hash for each polling location; 


Ensure that data is only accepted from actual authorized devices through the use 
of Digital Certificates; 


Be capable of downloading the complete election data for the current Election 
Day from any connected BCSs or Voting Stations; 


Calculate the Election Data Integrity Hash on the data downloaded from each 
device, and validate that it matches the Election Data Integrity Hash received via 
the internet from the polling location. Enable printing this hash with the audit 
data for comparison with the expected results from the polling location; 


Provide an appropriate interface for RSS workers to validate that the Election 
Data Integrity Hashes match the expected values, or warnings if they do not; 


Enable RSS workers to enter comments regarding any irregularities; 


Provide a means for all data collected at the RSS to be transmitted securely to the 
CCS over the internet or a private network. Provide the means to send this data in 
total, or incrementally (including only the data not yet sent previously); 


Provide the means to save data down to a write-once data storage device (such as 
a DVD-R) instead of transmitting over a network, while retaining the full 


functionality described for this module; 


At the CCS, the system must: 


4.3 


4.2.15 Provide a means of securely receiving (over the internet) the expected Election 
Data Integrity Hash from each polling location; 


4.2.16 Provide a means of downloading (directly from a connected BCS or Voting 
Station) or securely receiving (over the internet, and via write-once data storage 
devices such as a DVD-R) one or more sets of election data; 


4.2.17 Ensure that data is only accepted from actual authorized devices through the use 
of Digital Certificates; 


4.2.18 Calculate the Election Data Integrity Hash on the data downloaded from each 
device, and validate that it matches the Election Data Integrity Hash received via 
the internet from the polling location; 


4.2.19 Provide an appropriate interface for RSS workers to validate that the Election 
Data Integrity Hashes match the expected values, or be shown warnings if they do 
not; 


4.2.20 Provide a mechanism to consolidate all the data received and write it onto a write- 
once data storage device (such as a DVD-R) for transfer to the Tabulation 
module; 


Bulletin Board Module 


A web interface must be provided for disclosure of public audit data and for enabling 
voters to look up the status of their ballot based on the hash on their receipt. This RFP 
limits the Bulletin Board to internal use only, where citizens may come in to 
Administrator’s office to perform any election verification operations. The Bulletin Board 
also provides a way for voters to check that the encrypted cumulative tally posted at the 
polling location at the end of Election Day is the same as those reported to and used at the 
Counting Station. 


These requirements also provide an Audit Data API, web service or other suitable 
interface portal that creates a standard access layer for independent analysis of information 
and verification data. 


This interface must include the ability to provide all information for multiple elections and 
for each election must include: 


4.3.1 A means to access a digitally signed file containing all public audit data from the 
election; 


4.3.2 A list of hashes of all Electronic Vote Records from the election. Next to each 
hash must be either: 


4.3.2.1 An indication that the related ballot is fully cast; 
4.3.2.2 An indication that the related ballot is spoiled (not cast); or 
4.3.2.3 An indication that some, but not all, pages of the voter’s ballot are cast; 


4.3.3 A look-up tool for cast ballots (ballots placed in the ballot box at the polling 
location) that enables a voter to type in the hash from the receipt, view the hash in 
a list of hashes representing all cast ballots, and view the status of his or her vote; 


4.3.4 A ballot look-up tool that enables the voter to enter the receipt hash code and look 
up his or her ballot’s status. This can take the voter to the appropriate point in the 
hash list or a separate status page. For spoiled or partially cast ballots, this must 


include a means to view the decryption of any spoiled pages of the ballot unless 
inclusion of spoiled ballot decryptions was disabled by election administrators; 


4.3.5 Access to a digitally signed file containing the commitment to the mixed plain- 
text votes for use by observers during the Risk Limiting Audit; 


4.3.6 Unofficial tallies for each candidate/option in each race, broken out by precinct 
and stored in XML/JSON/Human Readable; 


4.3.7 A list of the hashes of encrypted totals from each polling location that can be 
matched up with the hash totals posted on the doors of the polling locations. 


4.3.8 A complete list of valid PEVR hashes from the election, as well as the status of 
each (cast/partially cast/spoiled); 


4.3.9 A complete set of PEVRs, including the status of each (cast, spoiled, partially cast 
with cast pages specified); 


4.3.10 A complete dump of an audit log from each polling location; 
4.3.11 The Audit Plaintext Commitment file; and 


4.3.12 For each Election Day, an indication must be provided both on the page and in the 
files specifying whether the data is preliminary, final pending audit, or audited. 


For the Election Results and Audit Data API, web service or other suitable interface 
portal, the system must: 


4.3.13 Interface with and provide relevant data to the Administrator’s existing Election 
Night Reporting system (ENR) and website; 


4.3.14 Provide an Application Programming Interface (API), web service or other 
suitable interface portal for accessing election results and audit data; 


4.3.14.1 This API, web service or other suitable interface portal must make use of 
modern web standard technologies (e.g. ODATA) and be fully documented; 
and 


4.3.14.2 The API, web service or other suitable interface portal must enable 
discoverability of available data, under the assumption that other election 
Administrator may provide data through the same source (i.e. other counties 
could join with Travis County to provide a central electronic repository for all 
the counties’ official election records, and this should require no software 
changes either to the API or to properly written API consumers). 


For election verification data generated by the Tabulator module, the Bulletin Board must 
provide a simple web page that includes and allows for the download of the following 
digitally signed files: 


4.3.15 Official tallies for each candidate/option in each race, broken out by precinct and 
stored in XML/JSON/Human Readable format; 


4.3.16 A list of the hashes of encrypted totals from each polling location that can be 
matched up with the hash totals posted on the doors of the polling locations. 


4.3.17 A complete list of valid PEVR hashes from the election, as well as the status of 
each (cast/partially cast/spoiled); 


4.3.18 A complete set of PEVRs, including the status of each (cast, spoiled, partially cast 
with cast pages specified). Unless disabled by election administrators, spoiled or 
partially cast ballots also include the decryptions of any spoiled pages, with the 
exception of Provisional spoiled or partially cast ballots; 


4.3.19 The list of Election Data Integrity Hashes for each polling location, for each day 
the polls were open which must encompass all in-person voting data included in 
the audit data; 


4.3.20 The Audit Plaintext Commitment file; and 


4.3.21 For each Election Day, an indication must be provided both on the page and in the 
files specifying whether the data is preliminary, final pending audit, or audited. 


5.0 REQUIREMENTS FOR OPEN SOURCE REFERENCE MODULES 


The successful proposer must include certain components that are released to the public as “open 
source” under a license that permits both derivation and use of the code and its derivatives without 
permission or payment of royalties or licensing to the vendor. This must include at a minimum 
those components listed within this section, but the vendor may propose to make other components 
of the software open source as they deem appropriate. 


5.1 Guiding Principles: 


5.1.1 


Any component whose precise operation must be known in order for an independent 
auditor to reproduce or interpret any output of the system described within this RFP, or to 
recreate any audit procedure enabled by this RFP, shall be made open source; and 


At any point where components of the system interact there shall be released an open 
source and functioning reference implementation that could be substituted in on either 
side of the interaction such that it could correctly interpret any intermediate outputs of a 
component of the system, or correctly produce valid inputs to the component of the 
system. 


5.2 The minimum set of components to be released as open source for general use are: 


5.2.1 


52.2 


Polling Location Network Traffic Inspector 


A working reference implementation of software that can: 


5.2.1.1 Connect to and interface with a polling location’s network; 


5.2.1.2 Receive, interpret, and verify all messages from other devices on the network; 
and 


5.2.1.3 Present a human-readable representation of the data captured; 
Public Audit Data Inspector and Verifier 


A working reference implementation of software that can: 


5.2.2.1 Consume the publicly released audit data; 


5.2.2.2 Verify the NIZK proofs and cryptographic hashes of electronic vote records, 
and the integrity of hash chains; 


5.2.2.3 Given the cryptographic hash from a Voter’s receipt, look up the Voter’s 
electronic vote record, and: 


5.2.2.3.1 If the electronic vote record is marked “cast” or “provisional 
accepted”, determine whether the electronic vote record is 
included in relevant tallies; 


02-202 If the electronic vote record is not marked as “cast” or 
“provisional”, locate its decryption, verify that this decryption is 
correct, and display the decrypted selections to the voter. 


5:2:3 Ballot Style Definition Inspector 


A working reference implementation of software that can: 


5.2.3.1 Read in digitally signed files containing ballot style definitions; and 


5.2.3.2 Make use of the shared Ballot UI to demonstrate how each ballot style is 
presented to a voter, including non-visual elements. 


5.2.4 Public Tally Verifier 


A working reference implementation of software that can: 


5.2.4.1 Consume the publicly released audit data; 


5.2.4.2 Independently calculate encrypted tallies from the included electronic vote 
records that are marked as cast; and 


5.2.4.3 Verify the correctness of the official tallies using the independently calculated 
encrypted tallies, and the NIZK proofs released alongside the official tallies; 


5.2.5 Any element that is this requires to be implemented as a Componentized Software 
Element must include an open-source reference implementation of a software module 
which could be used in place of the module included as part of the proposed software. 
This requirement may be met by releasing the portion of the proposed software that 
implements that Componentized Software Element as open-source. 


6.0 REQUIREMENTS FOR BACK UP AND ARCHIVING MODULE 


When voting devices are returned to the Administrator after Election Day, a process must occur to 
back up and archive all data resident on all devices. Methods, processes, storage, and reports for 
back up must be easily and clearly retrievable as forensic evidence in the case of a contest of 
election, and the entire election should be easily reconstructed for review. 

The system must: 


6.1 Provide a means for efficiently backing up and archiving all data resident on all devices after 
each election; 


6.2 Provide a means for parallel operations so that more than one device can be backed up at a 
time; 
6.3 Organize information so that it can be quickly searched and rapidly retrieved; and 


6.4 Create reports regarding the status of backup operations for each election. 


7.0 REQUIREMENTS FOR ACCESSIBILITY 


Giving all voters the right to vote using the same type of voting device is an important principle 
that drives the design of the STAR-Vote™ system. The STAR-Vote'M accessibility solution must 
give voters with a variety of disabilities the ability to vote and verify their paper record privately 
and confidently. The solution must include providing equal voting opportunities to curbside voters 
and voters who have their own preferred accessibility input devices (jelly switch, sip & puff, etc.). 


Any proposed system must: 
7.1 Provide the same type of equipment and processes as other voters whenever possible; 


7.2 With few exceptions, allow voters with disabilities the ability to cast a secret ballot by 
himself or herself; 


71.3 


7.4 


7.5 


7.6 


1.1 


Provide an audio tactile interface at any Voting Station; 
Be able to interface with new accessibility hardware as it emerges; 


Be designed to use standard generic accessibility interfaces and flexible enough to be 
installed on hardware for curbside voting (such as a tablet or touch-screen laptop) that can 
be taken outside by a poll worker; 


Support a pure visual interface (with optional large font, high contrast, etc.), a pure audio 
interface, and a synchronized visual/audio interface; and 


Must comply with all accessibility requirements of the Voluntary Voting System Guidelines 
(VVSG) v. 1.1 (2012), Help America Vote Act (HAVA), Americans with Disabilities Act 
(ADA), or any other more current and comprehensive version that may be released during 
the time this project is being completed. 


APPENDIX D 
SOFTWARE SPECIFICATIONS 


8.0 Software Specifications 


8.1 


8.2 


Quality of Design 


Every aspect of this software must be: 


8.1.1 
8.1.2 
8.1.3 
8.1.4 


8.1.5 


Designed using coding best practices; 
Built using a logical and modular structure; 
Designed with thorough and meaningful comments and documentation; 


Engineered with for straightforward extensibility and interoperability with external 
components; and 


Built, implemented, and maintained using an industry standard version control 
solution. 


Modularity/Extensibility 


The system must: 


8.2.1 


8.2.2 


8.2.3 


8.2.4 


8.2.5 
8.2.6 


Make use of Componentized Software Elements that communicate through well- 
defined interfaces and are constructed, implemented, and referenced in a way that 
makes the replacement of any given module with an alternate as simple as possible; 


Have the ability to replace any software element needing replacement with a new 
element that serves a similar purpose; 


Replace components with minimal overhead. Ideally, this would be by selecting a 
new archive or library (such as DLL files in Windows) during configuration of the 
software as the proper component to use, without requiring a completely new 
software installation or distribution. This could entail the use of technologies such as 
.Net's Managed Extensibility Framework to completely decouple code publishing and 
make use of interfaces from components implementing them; 


Prohibit automatic loading of programs, or program components produced in 
fulfillment of this specification, into memory and executing newly introduced 
software in an attempt to achieve modularity. Before any newly introduced 
component is executed, the Administrator must select it for execution during 
configuration; 


8.2.4.1 For example, a model wherein any library file (such as a .dll under Windows) 
placed in a specific folder is automatically loaded is explicitly not allowed; 


8.2.4.2 At most, the software may read meta-data from such components to provide 
administrators with additional information about them to determine what 
interfaces the component satisfies, and to verify digital signatures; 


Be balanced with the minimal-attack-surface bias explained below; and 


Follow the minimum list of particular elements that must be contained within each 
Componentized Software Element as defined in the Shared Components section. 


8.3 


8.4 


8.5 


8.6 


Robustness 


8.3.1 The code must be resistant to failures, able to detect faults, and able to recover from 
failures where possible; and 


8.3.2 Where recovery is not possible, it must employ user-friendly error messages that aid 
both immediate recovery and future software improvement. Fatal errors must be 
logged with relevant exception information to aid future debugging. 


Minimal Attack Surface 


To minimize the attack surface of the code in all In Person Voting systems , the number of 
external dependencies on which the code relies must be minimized. Examples of this 
principle would be displaying User Interface (UI) elements as pre-rendered bitmaps, rather 
than using layout and text rendering inside of the final device, or preferring an audio format 
that is understood natively by the system and does not require an external codec to use. 
Please note that these precise methods are examples, not specific requirements or 
recommendations. 


Measurability 


8.5.1 The code must be designed to enable documentation of information at a detailed 
level. This shall include: 


8.5.1.1 Amount of time for UI elements to display; 
8.5.1.2 The number of ‘taps’ outside of touch-targets; 
8.5.1.3 The frequency of changing initial selections; and 


8.5.1.4 Any additional information potentially useful for measuring or validating the 
system’s performance. 


8.5.2 These data are not collected during normal election circumstances, but must support 
debugging and usability testing. Any measuring/logging logic that could violate, or 
create the appearance of violating voter anonymity must be contained in an alternate 
“debug” compile configuration such that final production binaries do not contain that 
code. 


Scalability and Adaptability 


The system must be: 


8.6.1 Flexible enough to adapt to new laws, requirements and guidelines, and procedural 
changes; 


8.6.2 Anticipate and have a strategy for regularly updating software, firmware, and 
hardware; 


8.6.3 Designed to anticipate that other counties in Texas and the United States will need to 
customize certain aspects of this software to meet their individual needs; and 


8.6.4 Designed in an organized structure that allows changes to be made efficiently and 
with minimal cost. 


8.7 General Security Requirements 


The system must: 


8.7.1 
8.7.2 
8.7.3 


8.7.4 


8.7.5 


8.7.6 


8.7.7 


8.7.8 


Be comprised exclusively of digitally signed assemblies; 
Automatically verify digital signatures on any loaded files; 


Verify all NIZK proofs on ballots received over the network, unless it proves too 
computationally intensive to execute in real time; 


Verify the integrity of hashes for new ballots, instructions, and other items involving 
hash chains from other machines on the network as they are received; 


Detect any malformed, erroneous, or unauthorized communication in the polling 
location during an election and immediately display a warning at the BCS. Examples 
of such communications include, but are not limited to: 


8.7.5.1 Receiving a ballot from a Voting Station not authorized to cast a ballot; 
8.7.5.2 Receiving a scanned PID for which no electronic vote record is known; 


8.7.5.3 Noting a hash on a received EVR that does not match the calculated hash 
based on the previous ballot received from that Voting Station; and 


8.7.5.4 Receiving a malformed or unrecognized message of any kind. 


Flag to poll workers on each BCS user interface any machine in use during an 
election that is detected to have behaved erroneously by other devices on the network; 
and 


Allow for the introduction of independent hardware into the network to capture traffic 
and independently audit network communication. 


Adhere to key lengths and hash sizes that meet or exceed the minimum bit length 
recommended for Level 7 security as described in section 7.2 of the ECRYPT II 
Recommendations, ICT-2007-216676 (2011); 


8.7.8.1 This implies at minimum: 128-bit symmetric keys, 3248-bit asymmetric keys 
and logarithm group keys, 256-bit Elliptic Curve group keys, and 256-bit 
hashes; and 


8.7.8.2 This may be reduced to Level 6 security provided that the homomorphic 
encryption Algorithm Selected does not require the release of full ciphertexts 
of encrypted ballots to enable independent homomorphic calculation of a 
commitment-consistent encrypted vote tally by members of the public; 


8.8 Air-Gapped Systems 


8.8.1 


8.8.2 


8.8.3 


All components in an Air-Gapped System must communicate with other devices 
exclusively through the use of the shared Network and Logging Layer except in such 
cases as are explicitly outlined below; 


Any communication not through the shared Network and Logging Layer must be 
logged; and 


The successful proposer must propose any additional software or functionality within 


8.9 


the Air-Gapped System necessary to ensure the complete system meets the logistical 
requirements of a practical election. 


8.8.4 The EAC Certified Modules may transfer data to/from the In Person 
Voting/Tabulation Modules using portable memory devices if support of the shared 
Network and Logging Layer is not a current feature of the individual certified 
products. 


Shared Components 


The shared components in the subsections below must be implemented as independent, 
compiled (if applicable) modules that can be included in final discreet software programs as- 
is, without modification. This requirement is waived if the component’s requirements are 
fully satisfied by elements of a software library that is publicly available, may be used in 
open source projects without licensing fees, and is used by this software. The list of shared 
components include: 


Cryptographic systems (detailed in Appendix E), data importers/exporters, digital 
signatures/certification authority, network and logging layer, and ballot display and 
interaction system. 


8.9.1 Data Importers/Exporters 


For any code used to take internal representations of data and write them to 
standardized data formats as described, or any code used to import data from those 
standardized data formats: 


8.9.1.1 The code must be written to be reusable and readily replaceable; and 


8.9.1.2 Any referencing code must be open to additional input/output modules 
supporting new formats with no modification to existing code, aside from, at 
a maximum, assigning new references from existing code to the new module. 


8.9.2 Digital Signatures/ Certification Authority 


The system must provide: 


8.9.2.1 A common software base for creating and validating digital certificates, 
signing data with them, and validating those signatures must be provided; 


8.9.2.2 To minimize the attack surface, the signing, certificate and signature 
validation must be performed by the software or a referenced library directly; 
and 


8.9.2.3 This requirement may be fulfilled by use of a third party library if that library 
is freely available for general use and inspection by the public. It may also be 
fulfilled through the use of system-level cryptographic APIs if and only if it 
properly leverages an available Trusted Platform Module, and the operating 
system supports UEFI secure boot technology. 


8.9.3 Network and Logging Layer 


The Network and Logging Layer provides for all network interaction between 
software systems within the Air-gapped portions of STAR-Vote™. The Network and 
Logging Layer acts as a message-based network transport layer, and: 


8.9.3.1 Broadcasts the device’s existence on the network to other STAR-Vote™ 
compatible devices; 


8.9.3.2 
8.9.3.3 


8.9.3.4 


8.9.3.5 


8.9.3.6 


8.9.3.7 


8.9.3.8 


8.9.3.9 


Discovers other STAR-Vote™ compatible devices on the network; 


Transmits well-formed messages from a device’s software to all connected 
STAR-Vote™-compatible devices; 


Digitally signs all such messages with the device’s election-specific 
certificate; 


Ensures that all messages received from any device are received by all 
devices. The referencing software may disable this function if the provided 
device certificate is not for a Voting Station, BCS, or Ballot Box/Scanner; 


Logs all messages received automatically, and ensures good ordering of the 
message log through retention of a hash chain; 


Enforces Device Roles — messages received from any device must only be 
accepted and passed along if the sending device has provided a valid digital 
certificate issued by the Election Certification Authority that specifies a 
Device Role enabling the type of message received; 


Assists newly-connected devices in reconstructing the historical audit log in 
the polling location for the current election (when requested by the device, 
and where applicable); and 


Uses messages with these constraints: 


8.9.3.9.1 Must have a format that is straight-forward to test that messages are 
well-formed; 


8.9.3.9.2 Be readily hashed; and 


8.9.3.9.3 Must not be modified at the software level prior to logging. 


8.9.4 Audit Plaintext Commitment File 


The system must provide: 


8.9.4.1 


8.9.4.2 


8.9.4.3 


In the tabulation process described in the In-Person Tabulator requirements 
and the Trustee Software requirements, production of a file of plaintext votes 
as one of its outputs and produce an Audit Plaintext Commitment File; 


For each Audit Plaintext Commitment File contained as part of its header, an 
indication of whether it is preliminary or final (all accepted provisional and 
write-in votes are incorporated, and the election results canvassed), and not 
subject to additional alteration; 


For this Audit Plaintext Commitment File, the complete set of plaintext votes 
for the election, including for each entry: 


8.9.4.3.1 The Race ID of the race in which that vote is cast; 


8.9.4.3.2 The Candidate ID of the candidate/option for which that vote is 
cast; 


8.9.4.3.3 The decrypted Audit Plaintext Reference Key for that vote; and 


8.9.4.3.4 If the vote is for a write-in, a decryption of the text written in by the 
voter; 


8.9.4.4 The Audit Plaintext Commitment File in two formats: a XML/JSON format, 
and a fixed-width, human readable, text format. 


8.10 Data Formats for Elements B and C 


All data that is transferred between local software programs or transferred between or 


from web systems must be contained in standardized data formats. The following 
conditions are required: 


8.10.1 The use of proprietary binary formats is not allowed; 
8.10.2 For data that must be hashed according to this document’s requirements: 
8.10.2.1 Data is stored using Google Protocol Buffers; 


8.10.2.2 The vendor is responsible for defining and providing the .proto files 
describing the data formats of every relevant information type consistent with 
the .proto language definition available here: 
https://developers.google.com/protocol-buffers/docs/proto 


8.10.2.3 In any instance in which the software interacts with these data formats, it 
must make use of code automatically generated from the relevant .proto file. 
Specifically, the vendor may not write their own implementation of either a 
protocol buffer reader or writer unless a canonical or functioning 
implementation is not available for the relevant language or software 
framework, in which case the vendor is responsible for contributing any 
resulting protocol buffer implementation back into the open source 
community and ensuring there are no legal impediments to doing so. 


8.10.2.4 For data that does not need to be hashed in accordance with this document’s 
requirements: 


8.10.2.4.1 The vendor must rely on industry standard data formats where such 
formats exist. Variations on or additions to any such standard must 
be documented and released along with the resulting software; 


8.10.2.4.2 Where no standard exists and the data does not need to be hashed, 
XML/JSON/Human Readable must be used if possible including a 
well-defined schema describing correctness for each format, or, 
where a variety of data types are required, a standard compressed 
archive file format that includes an XML/JSON/Human Readable 
manifest file is used; and 


8.10.2.4.3 Where the data does not need to be hashed, no standard exists, and 
XML/JSON/Human Readable is not appropriate; formats that can 
be inspected with standard software tools such as a text editor, 
zip/rar/7z file inspector, or a combination of such standard tools are 
required. 


Details related to specific data formats with additional requirements are laid out in the 
subsections below. 


8.10.3 Electronic Vote Record (EVR) 
The EVR must include: 


8.10.3.1 Each race stored as a Single Race Selection Vector (SRSV), that is a data 
structure containing: 


8.10.3.1.1 The Race ID for the race for which this SRSV encodes selections; 


8.10.3.1.2 An encrypted counter for each candidate/option with the following 
requirements: 


8.10.3.1.2.1 Each counter contains the number of votes the voter has 
indicated for that candidate/option. This generally means 
that the counter must contain a 1 or O except in such case 
as a voter may vote more than once for a given 
candidate/option; 


8.10.3.1.2.2 Each counter must be encrypted using a Homomorphic 
Encryption Algorithm as described in this RFP and using 
the Election Public Key; 


8.10.3.1.2.3 The counter must be associated with the unique publicly 
disclosed candidate ID for that candidate; and 


8.10.3.1.2.4 Ifa write-in is permitted for the race, an encrypted counter 
for the write-in option must be included that contains a 1 if 
the voter’s selection is a write-in vote and 0 otherwise; 


8.10.3.1.3 A hash of the Race Identifier (RID) combined with the Page 
Identifier (PID) for the page of the PVR on which this race is 
displayed. This hash must then be encrypted with the Election 
Public Key; 


8.10.3.1.4 If a write-in is permitted, an encrypted text field in which the 
voter’s write-in may be stored; 


8.10.3.1.4.1 This field must be either an encryption of the voter’s 
write-in (if the voter selects to vote for a write-in 
candidate), or an encryption of an empty string; 


8.10.3.1.4.2 Each time a SRSV is created without a write-in candidate 
selected, a new encryption of the empty string must be 
calculated to avoid violating the anonymity of write-in 
voters; 


8.10.3.1.5 The random seed used to initialize the encryption algorithm just 
before this SRSV is created must be encrypted with the Election 
Public Key and stored as part of the SRSV; 


8.10.3.2 A vector of the Page Identifiers (PIDs) for each page of the associated PVR, 
encrypted using the Election Public Key (used to reconstruct the plaintext 
EVR during a risk-limiting audit); 


8.10.3.3 A vector of the Page Casting Identifiers (PCIDs) for each page of the 
associated PVR, encrypted using the Election Public Key (used to reconstruct 


the plaintext EVR during a risk-limiting audit); 


8.10.3.4 For each connected BCS, a vector of Page Casting Identifiers (PCIDs) for 
each page of the associated PVR, encrypted using that BCS’s public key 
(separately, so that each BCS can correctly decrypt one copy of the vector). 
Each vector must be annotated in some manner such that each BCS can 
determine which copy of the vector it should be able to decrypt; 


8.10.3.5 For each Electronic Vote Record, a Non-Interactive Zero Knowledge (NIZK) 
Proofs sufficient to demonstrate that it is well formed: 


8.10.3.5.1 Every candidate/choice must include a NIZK proof that the 
candidate/choice’s vote counter is either 0 or 1 (unless more than 
one vote is allowed for a candidate in that race, in which case the 
NIZK must prove that the voter has not cast more votes than are 


permitted); 


8.10.3.5.2 Any race in which only one candidate/choice may be selected must 
include a NIZK proof that the sum of the available candidates’ vote 
counters is either 0 or 1; 


8.10.3.5.3 For a vote for K of N races, or races in which more than one vote 
may be cast, an appropriate proof must be included to provide a 
high degree of confidence that the ballot is well formed; 


8.10.3.5.4 For Write-in candidates, a NIZK proof must be included to ensure 
that the write-in slot contains a string or the associated counter is 
zero. The NIZK proof must be included whether or not a write-in 
vote is cast in order to ensure vote anonymity; and 


8.10.3.5.5 Itis suggested that proposals make use of Sigma and 
disjunctive Fiat-Shamir proofs, though no preference will be 
given to proposals making use of these technologies. See 
Attachment 8 for further discussion. 


Further requirements for the EVR are that: 


8.10.3.6 The EVR must be stored as a Google Protocol Buffer, and the structure of the 
EVR must be that it includes two items: 


8.10.3.6.1 A required PEVR; 


8.10.3.6.2 An optional data structure that contains all of the data required by 
the EVR, but that is not in the PEVR; and 


8.10.3.7 A voter’s selections in an EVR may not be stored in an unencrypted form in 
non-volatile memory for any reason during an election, and portions may 
only be stored in unencrypted form after an election if those portions are 
determined to have been spoiled (not part of the final vote tally); 


8.10.4 Public Electronic Vote Record (PEVR) 


The Public Electronic Vote Record (PEVR) is a version of the EVR for public 
distribution. It has the property that it: 


8.10.4.1 Allows a member of the public to calculate a Homomorphically Encrypted 
sum of the votes for each candidate when a complete list of PEVRs are 
released; 


8.10.4.2 When combined with information published by Election Officials, allows a 
member of the public to verify the validity of the vote selections, and that the 
official tallies are released correctly and reflect the votes contained in the 
PEVRs. 


8.10.4.2.1 Encryptions of the PIDs and PCIDs are not included in the PEVR. 


8.10.4.2.2 The precise information that must be included in the PEVR 
depends on the Homomorphic Encryption algorithm selected. 
For example, if ElGamal Encryption is selected, the PEVR 
encryptions will be equivalent to the EVR encryptions; 
whereas if PPAT1 is selected, the PEVR would not include the 
complete cyphertext. See Attachment 8 for further discussion 
(In the technical discussion in Attachment 8, the cryptographic 
data included in the PEVR is governed by the CCEXT() 
function [Commitment-Consistent Extraction] for a given 
algorithm); 


8.10.4.3 The PEVR must be stored as a Google Protocol Buffer; and 


8.10.4.4 The PEVR must contain a hash of the data structure, as described previously, 
from its associated EVR. 


APPENDIX E 
CRYPTOGRAPHY 


9.0 REQUIREMENTS FOR CRYPTOGRAPHY 


The cryptographic system for STAR-Vote™ consists of four core technologies —homomorphic 
encryption; commitment-consistent proofs of correct decryption; non-interactive zero-knowledge 
proofs; and a distributed threshold key creation/decryption system. Additional technical 
information on the cryptographic requirements can be found in Attachment 8: “STAR-Vote™ 
Cryptographic Aspects.” 


9.1 Encryption of vote tallies and other information as provided in this RFP requires an 
encryption algorithm with the following properties: 


9.1.1 Additive homomorphism — There must be an operation that, when applied to an 
encryption of n and an encryption of m, yields an encryption of n+m; 


9.1.2 Commitment consistency — Given an encryption, it must be possible to provide a 
proof that the encryption is a valid encryption of its known decryption; 


9.1.3 Non-Interactive Zero-Knowledge proofs — It must be possible to provide NIZK 
proofs that an encrypted ballot has a legal and well-formed decryption; 


9.1.4 Compatibility with a threshold key generation scheme; 


The recommended algorithm is exponential ElGamal. If using exponential ElGamal, a further 
recommendation is ElGamal over elliptic curves to substantially reduce the size of ciphertexts and 
resolve the issue discussed in Attachment 8, section 2.3. The County will consider alternate 
algorithms that would not require publishing of full ballot ciphertexts as part of the audit process 
(such as PPAT1). Additionally: 


9.1.5 The algorithm chosen must be clearly specified and justified in the proposal; 


9.1.6 The method by which the selected cryptographic system will address any difficulties 
that would be expected in its practical implementation (including, but not limited to 
those discussed in Attachment 8) must be clearly stated. 


9.1.7 For other elements of the system requiring encryption, use generally accepted 
standard encryption algorithms, provided that each algorithm to be used is specified 
in the proposal; and 


9.1.8 Separate each encryption system into a software module that is designed to be 
readily replaceable in the event advances in cryptanalysis or computer technology 
renders a part of the encryption system insecure. 


9.2 Homomorphic Encryption 


Votes stored in electronic vote records (EVRs) are encrypted using an additively 
homomorphic, commitment-consistent threshold encryption scheme, most likely 
Exponential ElGamal for this initial implementation. An additively Homomorphic 
Encryption algorithm is one that provides a means to take two encrypted numbers and 
combine them into an encryption of the sum of the two numbers. 


Each EVR contains a slot for an encrypted vote (0 or 1) for each candidate/option for 
which that voter is authorized to cast a vote. Because of the additive homomorphic 
property, given a set of EVRs with encrypted votes of 0 or 1 for each candidate/option on 


the ballot, it is possible to homomorphically combine all the encrypted votes and arrive at a 
valid encryption of the tally for each candidate/option without ever decrypting individuals’ 
votes and therefore compromising their privacy. Here is an illustration of this principle: 


EVR1 EVR 2 sis EVR n Encrypted Tally 
Candidate1 E(v11) E(v21) E(Un,1) E(tally,) 
Candidate 2 E( v4 9 E(v>5 El, E(tally2) 
) ® ( , ) (am) o ® ( n, ) = 
Candidate k E(v, x) E(v2x) E(Unx) E(tally;) 
9.3 Commitment Consistent Proofs of Correct Decryption 


9.4 


Commitment Consistency, the second property of the selected encryption system, means 
that given that you have an encryption of n, p(n), if another party claims that they are able 
to decrypt E;,,(n) and that its decryption is n, they can provide additional information to 
prove that E;,(n) is a valid encryption of n, and can do so with very high confidence, 
without providing the decryption key. 


In the case of STAR-Vote™, because the homomorphic property allows members of the 
public to independently create an encrypted tally, commitment consistency makes it 
possible for election officials to prove that the officially released tally is a valid decryption 
of that encrypted tally. Because the public knows which PEVRs are included in that tally, 
this method effectively enables members of the public to independently verify the 
complete set of PEVRs that are included in the tally, and verify that the published tally 
corresponds to the sum of these votes. 


When a voter finishes voting in a polling location, he or she receives a written 
confirmation with a 15-20 digit alphanumeric code on it. This code is the cryptographic 
hash (for a selected and public cryptographic hash function, most likely SHA256) of the 
PEVR containing their votes. This is an oversimplification to make the process clearer. In 
truth, the hash involves additional information, including the previous voter’s hash to 
increase tamper resistance. When the election night results are posted and the complete set 
of PEVRs is published, interested members of the public can independently calculate the 
cryptographic hash of every PEVR that has been proven to be counted in the final tally. 


Non-Interactive Zero-Knowledge Proofs 


Non-Interactive Zero-Knowledge (NIZK) proofs are used extensively to support 
independent verification of encrypted data without revealing the contents of that data. The 
specific scenarios in which NIZK proofs must be included are: 


9.4.1 Proving that a given encrypted vote counter for a given candidate/option in an 
EVR is either 0 or 1 (In the common case that the race only allows a single vote); 


9.4.2 Proving that the given encrypted vote counters for all of the options in a race sum 
to no more than the maximum allowed number of votes for that race; 


9.4.3 Proving that the write-in vote counter for a given race is either 0 or 1, and that if it 
is 1, the write-in text slot contains a valid string; and 


9.5 


9.4.4 Proving that the published plaintext vote tally corresponds to an independently 
calculated encrypted homomorphic sum of the PEVRs (or portions of PEVRs) that 
are released in tandem with the unofficial and final official results, and that are 
marked as ‘cast.’ 


Distributed Threshold Key Creation/Decryption (Trustee System) 


The final technology key to ensuring the relative privacy of voters once their votes are 
received is the Threshold Public Key Encryption that is used to create the Trustee System. 
Threshold Public Key Encryption allows you to have n individuals generate separate 
private/public key pairs (as would be used in traditional asymmetric key encryption), and 
from their public keys calculate a combined threshold public key for a selected threshold k 
(where k < n), that may be used to encrypt data such that in order to decrypt that data, at 
least k of the original private keys must be available. 


The advantage is that a single public key can be created that encrypts all vote data and 
requires multiple individuals, the Election Trustees, to cooperate in order to decrypt it. 
The Election Trustees are composed of multiple individuals with differing interests (party 
representatives, members of the local Election Board, etc.) to minimize the likelihood of 
collusion. In order to decrypt any votes, at least the agreed upon threshold number of 
Trustees must be present and take part in the process. Under such a system it becomes 
nearly impossible for a single individual or even an entire election office to violate the 
privacy of voters or the integrity of the election via the electronically stored votes. 


For key creation and appropriate security level, the system must: 


9.5.1 Adhere at a minimum to the general security requirements outlined in Appendix D, 
Section 8.7.8; and 


9.5.2 Generate threshold joint encryption keys from a set of independently generated 
public keys — i.e. individual threshold keys may not be derived from a master 
public/private key or key pair. 


9.5.3 Adhere to key lengths and hash sizes that meet or exceed the minimum bit length 
recommended for Level 7 security as described in section 7.2 of the ECRYPT II 
Recommendations, ICT-2007-216676 (2011); 


9.5.4 This implies at minimum: 128-bit symmetric keys, 3248-bit asymmetric keys and 
logarithm group keys, 256-bit Elliptic Curve group keys, and 256-bit hashes; and 


9.5.5 This may be reduced to Level 6 security provided that the homomorphic 
encryption Algorithm Selected does not require the release of full ciphertexts of 
encrypted ballots to enable independent homomorphic calculation of a 
commitment-consistent encrypted vote tally by members of the public; 


APPENDIX F 
HARDWARE REQUIREMENTS 


10.0 REQUIREMENTS FOR HARDWARE 


10.1 Areas Where Equipment and Devices Are Required 
Successful proposers must provide information on equipment and devices required for: 


Operation of Modules: This includes equipment and devices (including servers, 
computers, scanners, barcode readers, printers, paper handling equipment, furniture for 
supporting this equipment, etc.) for RFP Elements A, B and C; 


Early Voting and Election Day Polling Locations: This includes equipment and devices 
(including servers, computers, scanners, barcode readers, printers, paper handling 
equipment, furniture for supporting this equipment, etc.) for the Ballot Control Stations, 
Voting Stations, Audio Ballot Readers, Ballot Box/Scanner. Accessibility hardware is also 
required and when possible should be a first-class input mechanism; 


Ballot-by-Mail: This includes equipment and devices (including servers, computers, 
scanners, barcode readers, printers, paper handling equipment, furniture for supporting this 
equipment, etc.) for activities to support the preparation of unvoted and voted by-mail 
ballots; 


Storage and Transportation: This includes equipment and devices (including specialized 
shelving, carts, etc.) needed to store, manage, and maintain the equipment; and 
Other Administrative Requirements: This includes any other equipment or devices 
determined necessary by the Proposer. 

10.2 Mechanical, Electrical, Software/Firmware and Accessibility Requirements 


All proposed hardware and associated Software/Firmware shall meet the VVSG 
requirements for mechanical, electrical, software/firmware and accessibility. The 
following paragraphs contain additional requirements and desirable characteristics, the 
latter being used as a subjective component during proposal evaluation. 


10.3 Plan for the Storage, Transportation, Handling, and Maintenance of Hardware 


Proposer must include information on: 
10.3.1 How equipment is to be stored, transported, handled, and maintained; 


10.3.2 Special containers or transport tools that can be used to ensure equipment is 
secure from damage; 


10.3.3 Devices or physical arrangements that can be used to operate software and data 
image distribution and archiving; 


10.3.4 Securely storing equipment at polling locations. 
10.4 General Desirable Characteristics for the Polling Location 


10.4.1 The design for the polling location must incorporate modern, imaginative, easy- 
to-use, and cost-effective solutions; 


10.4.2 The equipment must be familiar to the types of computing equipment voters see 
in their daily lives; 


10.4.3 Components in the polling location must consist of minimal, lightweight, and 
easy-to-assemble equipment and devices. The physical setup and breakdown of 
the polling location should be easy to understand and require minimal effort or 
strength. Consideration must be given to the fact that many poll workers are older 
citizens. For example, a vendor might propose a type of computer privacy 
screens that could replace bulky booth wings. That simple change allows a voting 
station to go from being bulky furniture that requires complicated instructions and 
a team of two to assemble to involving a simple, lightweight device that clamps to 
a table or another easy-to-assemble pole structure.) 


10.4.4 The design must: 
10.4.4.1 Protect the ability for the voter to vote a secret ballot; 


10.4.4.2Be composed of equipment and mountings that are compact enough to, 
when necessary, accommodate as many voters as possible in sometimes 
small and unusually shaped polling locations; 


10.4.4.3 Be flexible in its use so as to promote efficient and intuitive workflows 
for election workers and voters; 


10.4.4.4Be adaptable and easily accept adjustments in equipment size so that new 
models of computers and printers do not necessitate the purchase of new 
voting booth structures. 


10.4.4.5 Accommodate persons with physical limitations and meet any 
accessibility guidelines applicable to the polling location; and 


10.4.4.6Have visual appeal that is inviting for voters versus intimidating or 
confusing. 


10.4.4.7 Provide a means for sealing and securing the BCS and Voting Stations for 
storage and transport before and after the polls are closed (for example, 
tamper-resistant evidence bags). 


10.4.4.8 Provide a means for sealing and securing the Ballot Box/Scanner for 
storage and transport before and after the polls are closed. 


10.5 Hardware Requirements: Voting Station Computers 


These devices must have: 


10.5.1 A structure that is similar to a tablet in that it is lightweight, portable, and has a 
long battery life; 


10.5.2 A minimum 5-point multi-touch touchscreen; 


10.5.3 An audio jack, including the ability to detect whether a device is plugged into that 
jack; 


10.5.4 The ability to run on battery power for long periods of time — all batteries must be 
rechargeable; 


10.5.5 A battery internal to the device or connected via cable; 


10.5.6 Ethernet network connectivity, including the ability to detect connection status 
changes; 


10.5.7 Support standards-compliant accessibility devices via industry-standard 
technologies; 


10.5.8 Printer support; 
10.5.9 A method for securely blocking ports from unauthorized use; 


10.5.10Ports securely mounted to minimize damage from frequent connection and 
disconnection of cables; and 


10.5.11The ability to be used in a parallel distribution of software and System Images, 
backup, data retrieval and clearing the memory; type and brand of touch screen 
display; 


10.5.12Dimensions overall, screen size and aspect ratio, and weight; 
10.5.13Screen resolution; 


10.5.14Time of operation if power goes out and recommendations for backup power 
supply; 


10.5.15Electrical requirements and energy consumption levels; 
10.5.16Screens or other methods available to protect voter privacy; 
10.5.17Activation information (exposed finger, fingernails, pointers, gloves, etc.); 


10.5.18Calibration requirements, procedures to perform this function and recommended 
frequency; 


10.5.19Top five most common repair or failure issues for this type and brand of device; 
10.5.20Estimated life span of device; 

10.5.21 Requirements for storage; 

10.5.22Requirements for transport; 

10.5.23Requirements for environmental control (temperature, moisture, etc.); 


10.5.24Available methods for mounting to and removing from poles or stands that could 
be used by voters and voters in wheel chairs; 


10.5.25Use in a curbside voting situation; 


10.5.26Any special transportation cases or devices that are recommended or required to 
prevent damage of equipment; 


10.5.27Recommended procedures for equipment preparation for use; 
10.5.28Recommended procedures for equipment preparation for storage; and 
10.5.29Maintenance and support levels; 


10.6 Hardware Requirements: Printer for PVR and Voter Receipt 


The requirements listed below are based on the use of thermal printers, however, 
alternative technologies may be proposed. 


The printers must: 
10.6.1 Be able to accept 8 1⁄2” x 11” and 8 12” x 14” paper; 


10.6.2 Print paper in sheets (roll paper will be considered, if there is a way to ensure a 
means for cutting or perforating the receipt and if there is a way for the PVR to 
lay and stay flat after 1t is cut from roll, will be considered); 


10.6.3 Detect low or out of paper conditions; 

10.6.4 Paper replacement procedure; 

10.6.5 Detection of jams or other physical malfunctions or error states; 
10.6.6 Service maintenance requirements; and 


10.6.7 Provide a cost justification for the initial purchase and ongoing operation; 


Justification as to why this type of device and brand are recommended must include 
information on: 


10.6.8 Type and brand of printer; 
10.6.9 Dimensions and weight; 
10.6.10Quality of printed image; 


10.6.11Time of operation 1f power goes out and recommendations for backup power 
supply; 


10.6.120Options for types of paper (including thickness, temperature, handling, and 
archive length tolerances); 


10.6.13Number of sheets of paper that can be held at one time and options for increasing 
tray depths; 


10.6.14Electrical requirements and energy consumption levels; 
10.6.15Methods for ensuring voter privacy while printing is occurring; 


10.6.16Calibration requirements, procedures to perform this function and recommended 
frequency;; 


10.6.17Top five most common repair or failure issues for this type and brand of device; 
10.6.18Estimated life span of device; 

10.6.19Requirements for storage; 

10.6.20Requirements for transport; 

10.6.21 Requirements for environmental control (temperature, moisture, etc.); 


10.6.22Available methods for mounting to and removing from poles or stands that could 
be used by voters and voters in wheel chairs; 


10.6.23Use in a curbside voting situation; 


10.6.24Any special transportation cases or devices that are recommended or required to 
prevent damage of equipment; 


10.6.25Type, longevity, and cost of consumables required; 
10.6.26Recommended procedures for equipment preparation for use; 
10.6.27Recommended procedures for equipment preparation for storage; and 
10.6.28Maintenance and support levels. 


10.7 Hardware Requirements: Ballot Controller Station Devices 


The device must have: 
10.7.1 A minimum 5-point multi-touch; 


10.7.2 Audio jack, including the ability to detect whether a device is plugged into that 
jack; 


10.7.3 One or more rechargeable batteries for supporting hardware (routers, etc.) 
connected via cable; 


10.7.4 Ethernet network connectivity, including the ability to detect connection status 
changes; 


10.7.5 Printer support; 


10.7.6 Ports securely mounted to minimize damage from frequent connection and 
disconnection of cables; and 


10.7.7 Ability to be used in a parallel distribution of System Images, backup, data retrieval 
and clearing the memory; 


10.7.8 Type and brand of touch screen display; 
10.7.9 Dimensions overall, screen size and aspect ratio, and weight; 
10.7.10Screen resolution; 


10.7.11Time of operation if power goes out and recommendations for backup power 
supply; 


10.7.12Electrical requirements and energy consumption levels; 
10.7.13Activation information (exposed finger, fingernails, pointers, gloves, etc.); 


10.7.14Calibration requirements, procedures to perform this function and recommended 
frequency;; 


10.7.15Top five most common repair or failure issues for this type and brand of device; 
10.7.16Estimated life span of device; 

10.7.17Requirements for storage; 

10.7.18Requirements for transport; 


10.7.19Requirements for environmental control (temperature, moisture, etc.); 
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10.7.20Available methods for mounting to and removing from poles or stands; 


10.7.21 Any special transportation cases or devices that are recommended or required to 
prevent damage of equipment; 


10.7.22Ease of connecting device versus ease of malicious individual disconnecting device; 
10.7.23Recommended procedures for equipment preparation for use; 
10.7.24Recommended procedures for equipment preparation for storage; 
10.7.25Maintenance and support levels; 


Printer for Voting Tickets 


The device must have the ability to: 

10.8.1 

10.8.2 Feed and cut roll paper; 

10.8.3 Detect low or out of paper conditions; 

10.8.4 Paper replacement procedure; 

10.8.5 Detect jams or other physical malfunctions or error states; 
10.8.6 Service and maintenance requirements; and 


10.8.7 Provide a cost justification for 


Justification as to why this type of device and brand are recommended must include 
information on: 


10.8.8 Type and brand of printer; 
10.8.9 Dimensions and weight; 
10.8.10Quality of printed image; 


10.8.11Time of operation if power goes out and recommendations for backup power 
supply; 


10.8.12Options for types of paper (including thickness, temperature, and handling 
tolerances); 


10.8.13Number of receipts that can be printed before roll has to be changed; 
10.8.14Electrical requirements and energy consumption levels; 


10.8.15Calibration requirements, procedures to perform this function and recommended 
frequency; 


10.8.16Top five most common repair or failure issues this type and brand of device has; 
10.8.17Estimated life span of device; 


10.8.18Requirements for storage; 
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10.8.19Requirements for transport; 
10.8.20Requirements for environmental control (temperature, moisture, etc.); 


10.8.21 Available methods for mounting to and removing from poles or stands, if 
applicable; 


10.8.22Use in a curbside voting situation; 


10.8.23Any special transportation cases or devices that are recommended or required to 
prevent damage of equipment; 


10.8.24Ease of connecting device versus ease of malicious individual disconnecting device; 
10.8.25Type, longevity, and cost of consumables required; 

10.8.26Recommended procedures for equipment preparation for use; 
10.8.27Recommended procedures for equipment preparation for storage; and 
10.8.28Maintenance and support levels. 


Hardware Requirements: Ballot Box/Scanner 


The Ballot Box/Scanner is composed of two parts — the scanner that receives/scans the 
PVR pages and the physical ballot box where the received paper is securely stored. As 
there is no known COTS products that satisfy the requirements listed below, the Ballot 
Box/Scanner will need to be a custom developed hardware component. In the interest of 
flexibility and cost management, Travis County will accept two different responses to 
satisfy the functional and operational requirements for the Ballot Box/Scanner. The 
following defines the two response categories: 


Ballot Box/Scanner Option 1: This response is for the complete development of the 
Ballot Box/Scanner according to the Ballot Box/Scanner requirements contained in this 
RFP. The response for this option is to be a standalone proposal that provides the proposed 
development, testing and certification of the hardware including development cost and 
production pricing. Also included in the Option 1 proposals is a proposed interim solution 
using a COTS computing device with a barcode scanner connected to it for reading the 
PVR barcode and communicating it to the other components for the system. The interim 
solution should also include a receptacle for the PVRs. Development and production cost 
should be separately provided for the interim solution as part of the Option 1 proposal. 


Ballot Box/Scanner Option 2: Any proposer that possesses certified ballot box/scanner 
hardware may propose their hardware to satisfy the STAR-Vote™ Ballot Box/Scanner 
requirements. This proposed solution must include the cost associated with the 
development of new software that meets the Ballot Box/Scanner functional and operational 
requirements contained in this RFP. In the event there are limitations imposed by the 
hardware for meeting all the Ballot Box/Scanner features and functions, these limitations 
should be noted in the response. Option 2 proposals must include the development, testing 
and certification costs and the production cost on per unit basis. Please note, the software 
developed as part of this option becomes property of Travis County and will be managed as 
“open source code” as defined in this RFP. 


10.9.1 The scanner portion of the Ballot Box/Scanner: 


10.9.1.1 Have Ethernet network connectivity, including the ability to detect 
connection status changes; 


10.9.1.2 Participate in the shared network and logging layer; 


10.9.1.3 Have sufficient memory to store/cache its own messages in the event it 
is disconnected from the network until it is reconnected and can 
broadcast them. Note that the device could lose power during this 
period, requiring that these messages be stored in non-volatile memory; 


10.9.1.4 Accept an election-specific certificate, device role, polling location, etc.; 


10.9.1.5 Have the capability for reading the barcode on PVRs and that is 
positioned such that it automatically reads the barcode of the current 
PVR page. This may optionally happen either when placed in the tray, 
or after the page has been partially fed into the scanner; and 


10.9.1.6 Have the ability to “accept” or “reject” each page physically via the feed 
mechanism once a Ballot Control Station has indicated over the network 
that the page should be accepted or rejected. 


10.9.1.7 Be able to accept 8 Y” x 11” and 8 Y” x 14” paper; 
10.9.1.8 Have a feed speed that accepts voter ballot pages without delay; 


10.9.1.9 Be able to accurately and consistently read barcodes printed off of 
thermal printers; 


10.9.1.10Be able to read barcodes that have been printed off of thermal printers 
that are nearing their time for consumable replacement; 


10.9.1.11Calibration requirements, procedures to perform this function and 
recommended frequency; 


10.9.1.12Have a means of signaling when equipment is not working or if a 
misfeed has occurred; 


10.9.1.13Feed one PVR page at a time; 
10.9.1.14Accept multi-page ballots; 


10.9.1.15 Include an internal, rechargeable battery with a specified time of 
operation if power goes out and the capability to operate using 
additional, external backup power supply 


10.9.1.16Have a method for securely blocking ports from unauthorized use; 


10.9.1.17Have ports securely mounted to minimize damage from frequent 
connection and disconnection of cables; and 


10.9.1.18 Accept software upgrades. 


10.9.1.19. Be capable of reading the ballot regardless of the orientation in which 
it is placed into the scanner (right side up, upside down frontwards, 
backwards) 


10.9.1.20Provides auditory and visual feedback to the voter when the ballot has 
been correctly cast 


10.9.1.21 Provides auditory and visual feedback to the voter when a ballot or 
other inserted document has been rejected and provide the voter with 
corrective action messages 


10.9.2 The Physical Ballot Box part of the Ballot Box/Scanner 


This is the part of the Ballot Box/Scanner where the PVRs automatically fall after 
they have been read by the Scanner portion of the device. The box must: 


10.9.2.1 Comply with the Texas Election Code Section 51.034 for Ballot Box number 
One: 


10.9.2.2 The box must be designed to accept any of the previously discussed PVR 
sizes and be connected to the device in such a way as to allow the PVRs to 
stack as neatly as possible when they fall within the box; 


10.9.2.3 The box must be designed in such a way as to easily connect and disconnect 
to the scanner portion of the Ballot Box/ Scanner while also having a way to 
protect any unauthorized separation to occur during voting; 


10.9.2.4 The box must be lightweight and easy to lift, hold, and load in an election 
worker or law enforcement official’s automobile; 


10.9.2.5 The proposal must give consideration to the shape, material, and labeling 
methods that are used for the box to ensure it can be efficiently stored, 
stacked, and tracked in a warehouse and handled in less than ideal 
circumstances in the field; 


10.9.2.6 It must prevent unauthorized access during the voting period either by the 
Ballot Box being opened for foreign material being inserted into it; 


10.9.2.7 Numbered tamper-resistant seals, locks, and/or other methods must be 
utilized to ensure the box has not been opened between the time it is officially 
sealed as empty to the time it is used for voting; 


10.9.2.8 Numbered tamper-resistant seals, locks, and/or other methods must be 
utilized to seal the ballot box following its official use in a polling location. 
Particular attention must be given to protect the box during transport and 
storage; 


10.9.2.9 If unauthorized tampering does occur, the box, the numbered tamper-resistant 
seals, locks, and/or other methods used for security should show that an 
attempt was made or that the security of the box breached; and 


10.9.2.10A documented chain of custody system must be provided to demonstrate how 
the box is protected during its custody by the Administrator, Election Judge, 
Law Enforcement Transportation Official, Early Voting Ballot Board, and 
Risk Limiting Auditors. 


10.9.2.11The ballot box shall be conspicuously labeled "Ballot Box" 


10.10 Hardware Requirements: Audio Ballot Reader 


The Audio Ballot Reader is an independent device that can aid visually-impaired voters in 
verifying their printed selections by scanning or imaging the Printed Vote Record (PVR) 
and providing an audible readout through an attached headset. Proposals may be based on a 
COTS product or a COTS product that requires modification. If modifications are 
required, additional design detail must be provided as given below. 


An Audio Ballot Reader must: 


10.10.1 Be easily accessible to voters and be small enough and inexpensive enough to be 
places at each voting station without creating a need for expanded booth space 
and/or set up as a separate station within the polling location; 


10.10.2 Standalone and have no network connection to the Voting Stations or BCS; 
10.10.3 Protect voter privacy during its use; 
10.10.4 Have an audio jack for a set of headphones; 


10.10.5 Have good fidelity so that selections heard through attached headphones are 
clearly audible in a space with significant crowd noise (vendor may recommend 
high quality affordable headphones that pair well with the Audio Ballot Reader); 


10.10.6 Have a means to conveniently activate the Reader when a ballot is set in place for 
reading; 


10.10.7 Have the ability to fully capture a PVR image (maximum legal-sized paper) from 
a distance of no more than 12”; 


10.10.8 Include an internal, rechargeable battery with a specified time of operation if 
power goes out and the capability to operate using additional, external backup 
power supply 


10.10.9 Have the means for securely blocking ports from unauthorized use; and 


10.10.10 Have ports securely mounted to minimize damage from frequent connection and 
disconnection of cables. 


10.10.11 If proposing a COTS device, type and brand of Reader as well as type of image 
capture device used to capture PVR images; 


10.10.12 Dimensions overall, including full description, and weight; 

10.10.13 Decibel range and maximum volume level; 

10.10.14 Time of operation if power goes out. Recommendations for power back up; 
10.10.15 Electrical requirements and energy consumption levels; 

10.10.16 Activation information (voice, touch, etc.); 


10.10.17 Calibration requirements, procedures to perform this function and recommended 
frequency; 


10.10.18 Top five most common repair or failure issues for this type and brand of COTS 
device; 


10.10.19 Estimated life span of device; 


10.10.20 Requirements for storage; 

10.10.21 Requirements for transport; 

10.10.22 Requirements for environmental control (temperature, moisture, etc.); 
10.10.23 Recommended methods for incorporating into the Voting Station set up; 
10.10.24 Use in a curbside voting situation; 


10.10.25 Any special transportation cases or devices that are recommended or required to 
prevent damage of equipment; 


10.10.26 Ease of connecting device versus ease of malicious individual disconnecting 
device; 


10.10.27 Recommended procedures for equipment preparation for use; 
10.10.28 Recommended procedures for equipment preparation for storage; and 


10.10.29 Maintenance and support levels. 
The Audio Ballot Reader must be equipped with software that must: 


10.10.30 Have the ability to be programmed to capture and read PVRs whose content and 
format changes from election to election; 


10.10.31 Have the ability to fully capture any designated contents of a PVR in any required 
language and read it back in a clear, easy-to-understand voice; 


10.10.32 Have the ability to be programmed to read designated PVR content; 
10.10.33 Have the ability to be programmed to read PVR content in a specified order; 


10.10.34 Have the ability to be programmed to easily correct mispronunciations of specific 
words and names; 


10.10.35 Have the ability to be programmed to associate specific pronunciations to specific 
words on the PVR; 


10.10.36 Give the voter the ability to activate the Reader through an accessible touch 
and/or voice method; 


10.10.37 Give the voter the ability to indicate completion of the use of the Reader through 
touch and/or voice; 


10.10.38 Give the voter the ability to easily have specific PVR selections reread; and 


10.10.39 Have the ability to be programmed so that a voter’s PVR is completely deleted 
from the memory of the Reader upon completion of the reading process. Have the 
ability to be programmed so that a voter’s PVR is completely deleted from the 
memory of the Reader upon completion of the reading process. 


10.10.40 Modified COTS proposals 


10.10.41 Provide design details of any required modification required for a proposed 
COTS product to meet the Audio Ballot Reader requirement. Design details must 


include mechanical or electrical modification and additional production costs for 
these modifications. 


APPENDIX G 
PROCEDURES, MANUALS, INSTRUCTION MATERIALS, AND TRAINING 


11.0 REQUIREMENTS FOR PROCEDURES, MANUALS, INSTRUCTION MATERIALS, 
AND TRAINING 


11.1 The vendor is responsible for producing procedures and manuals describing the proper use 
and maintenance of the System; 


11.2 Manuals must be produced explaining the proper use of all user- or administrator-facing 
aspects of the System. These must include, where appropriate, screen captures, diagrams, 
or other visual aids; 


11.3 Each process required to be performed by Elections personnel or poll workers that is 
related to, or dictated by, the System must have a written procedure; 


11.3.1 Each procedure must specify the purpose and expected result(s) of the procedure; 


11.3.2 Each procedure must be broken out into a checklist-style list tasks of sufficient 
granularity and description that there is a reasonable expectation that a person 
familiar with election management, but unfamiliar with the System, could 
successfully complete the procedure with limited or no training; 


11.3.2.1 Each task in a procedure should be a logical step in the process, not a specific 
action in the software; 


11.3.2.2 Each task in a procedure whose proper execution would not be expected to be 
self-evident to a person familiar with election management, but unfamiliar 
with the System, must have a textual explanation in one of the manuals with 
step-by-step instructions that is referenced by the procedure; 


11.3.2.3 Where the vendor, in consultation with the Administrative personnel, believes 
it appropriate, high-level procedures must be written, for which one or more 
‘tasks’ refer to separate procedures with their own list of tasks; 


11.3.3. This should be accomplished in part by referencing written instructions elsewhere 
in the manuals regarding the specifics of using particular components or interface 
elements of the various software systems; 


11.4 The vendor must provide materials to support the training of Elections personnel and poll 
workers in the proper use of the system; 


11.5. Election officials need thorough training and clear guidelines for the implementation and 
operation of the voting system. This includes a level of detail that enables the County to 
independently run all aspects of the voting system. For example, the hardware details 
necessary for STAR-Vote™ to function correctly must be written for a non-technical 
audience. These instructions also require best practices. For example, “network cables 
purchased for use with STAR-Vote™ machines should be of a uniform color (at least 
within a given polling location) and clearly distinct from any other colored network cables 
used for any equipment outside of the STAR Vote™ system. A sticker with the same color 
should be placed next to the network port on each device so that it is obvious which 
network cables to use”. Such simple best practices can substantially improve the security, 
reliability, and ease of use of a STAR-Vote™ deployment later on. 


11.6 The vendor must provide procedures for best practices for ensuring the security of the 
System and election data; 


11.7 The vendor must commit to work with the County”s personnel during the System 
development process, once the details of System use become clearer, to determine the 
appropriate scope, range, and granularity of procedures, manuals, and training materials. 


